Twitter: l'abus d'outils employés a créé un décalage de contrôle de la confiance publique

Résumé

• La prise de contrôle des comptes Twitter en juillet 2020 a transformé un problème privé de contrôle du support en un événement de confiance publique, car l'accès interne compromis a permis aux attaquants de publier depuis des comptes très visibles.
• Le dossier public comprend la communication de Twitter, l'enquête du département des services financiers de New York, les dossiers de poursuites du DOJ, les divulgations de risques de la SEC, le contexte de gouvernance de la FTC, la note d'atténuation de Coinbase et les rapports de sécurité sur l'attaque.
• La question du contrôle n'est pas seulement de savoir comment les attaquants ont obtenu l'accès. Elle est de savoir si Twitter a pu prouver que les outils privilégiés des employés étaient restreints, surveillés, repensés et adaptés aux conséquences publiques de l'autorité au niveau des comptes.
• La responsabilité était distribuée mais pas symétrique. Les attaquants et les ingénieurs sociaux ont causé l'abus immédiat. Twitter contrôlait les outils internes, l'accès des employés, l'authentification, la formation, la surveillance, les protections des comptes très en vue, la réponse aux incidents et l'avis public.
• La leçon durable est que les outils de support des plateformes sociales doivent être gouvernés comme des infrastructures publiques. Lorsque les contrôles internes peuvent réécrire la parole publique, ils ne sont pas de simples outils de back-office.

Le public voyait des paroles; les attaquants voyaient un plan de contrôle

L'incident Twitter de 2020 est souvent retenu pour le contenu le plus visible: des comptes très en vue ont publié des messages d'arnaque aux cryptomonnaies. Ce souvenir est exact mais incomplet. La leçon de responsabilité la plus durable est que les outils internes de gestion des comptes d'une plateforme sociale formaient un plan de contrôle sur la parole publique. Les utilisateurs voyaient des tweets. Les attaquants voyaient un chemin privilégié qui pouvait faire parler les comptes.

La mise à jour de Twitter sur l'incident de sécurité indique que les attaquants ont ciblé des employés par ingénierie sociale et ont utilisé les systèmes internes pour accéder aux comptes. Le département des services financiers de New York a ensuite publié un rapport d'enquête détaillé décrivant comment l'attaque s'est déroulée et pourquoi elle a exposé un risque plus large de gouvernance de la plateforme. Ces sources font le même point sous-jacent: l'intégrité des comptes ne dépend pas seulement des mots de passe des utilisateurs et de l'authentification à deux facteurs, mais aussi de l'autorité interne de la plateforme.

Cette distinction est importante pour la confiance publique. Un compte très en vue n'est pas seulement un identifiant. C'est un canal de communication publique. Il peut faire bouger les marchés, façonner les cycles d'actualité, diriger des partisans, solliciter des paiements, provoquer la panique ou induire en erreur des utilisateurs qui croient raisonnablement que le propriétaire du compte parle. Lorsque les outils internes peuvent outrepasser les protections côté utilisateur, la plateforme a le devoir de sécuriser ces outils en fonction des conséquences publiques qu'ils peuvent créer.

Le décalage est facile à énoncer. Le public attribue un sens au titulaire du compte. La plateforme attribue le pouvoir opérationnel aux employés et aux outils. Si la couche outil-employé est plus faible que la couche confiance publique, le public voit de l'authenticité là où le système de contrôle ne peut pas la garantir. Le piratage de Twitter a rendu ce décalage visible en quelques heures chaotiques.

C'est pourquoi l'incident ne peut pas être réduit à une histoire de sensibilisation des utilisateurs. Les propriétaires des comptes concernés ne sont pas tous tombés sur le même message de phishing. Le workflow interne de la plateforme était la surface contestée. Une plateforme peut encourager les utilisateurs à adopter une authentification forte, mais si les systèmes internes peuvent réinitialiser, modifier ou accéder aux contrôles des comptes sans une discipline équivalente, la sécurité côté utilisateur ne devient qu'une partie de la promesse.

L'ingénierie sociale des employés était un test de conception de la plateforme

L'ingénierie sociale est souvent discutée comme une faiblesse humaine. Dans le dossier Twitter, elle doit être traitée comme un test de conception du système. Les employés étaient la cible, mais la plateforme a choisi le nombre d'employés ayant un accès sensible, les conditions d'utilisation des outils, l'authentification requise, la surveillance autour de l'utilisation des outils, le workflow pour les demandes inhabituelles, et le rayon d'explosion en cas d'abus d'un identifiant employé.

Le communiqué de presse du NYDFS résumant le rapport a souligné la gravité de l'attaque et la nécessité d'une réglementation plus stricte de la cybersécurité pour les grandes entreprises de médias sociaux. Le détail du rapport est utile car il ne s'arrête pas à « les employés ont été trompés ». Il demande pourquoi les attaquants ont pu transformer l'accès des employés en prise de contrôle de comptes à grande échelle publique.

C'est le bon cadre de responsabilité. Une entreprise ne peut pas éliminer tout risque d'ingénierie sociale, mais elle peut rendre l'ingénierie sociale moins utile. Elle peut réduire l'accès privilégié, exiger une authentification plus forte, segmenter les outils de support, surveiller les actions inhabituelles, imposer un double contrôle pour les modifications de comptes à haut risque, limiter le taux des opérations sensibles, exiger des approbations juste-à-temps, protéger les comptes très en vue avec des restrictions supplémentaires, et former les employés à escalader les appels suspects.

Chaque choix de conception réduit la probabilité qu'une tromperie réussie devienne un abus public.

Les directives d'identité numérique du NIST dans SP 800-63B ne sont pas une norme spécifique à Twitter, mais elles aident à clarifier pourquoi la force de l'authentifiant et les contrôles de récupération de compte sont importants. Une plateforme qui gouverne des millions d'identités doit traiter sa propre authentification des employés comme faisant partie du système d'identité publique. Une assurance interne faible peut saper une assurance externe forte.

Les conseils Secure by Design de la CISA aident également ici. La charge ne devrait pas incomber uniquement aux employés individuels de résister à chaque appel trompeur. Les systèmes de produit et d'exploitation doivent être conçus de sorte que les défaillances humaines courantes ne produisent pas de résultats publics catastrophiques. Un outil de support qui peut affecter un chef d'État, une grande entreprise, une plateforme d'échange, une célébrité ou un compte média ne devrait pas se comporter comme un panneau d'assistance ordinaire.

La réponse responsable après un incident d'ingénierie sociale n'est donc pas un mémo disant que les employés devraient être plus prudents. C'est une refonte de l'accès. Quels outils étaient trop puissants? Quels utilisateurs avaient trop d'accès permanent? Quelles actions manquaient de deuxième examen? Quels journaux n'étaient pas surveillés? Quels comptes très en vue avaient besoin de protections supplémentaires? Quels workflows existaient pour les exceptions d'urgence? Quels groupes d'employés pouvaient agir sur des comptes qu'ils ne supportaient pas?

Ces questions déplacent la discussion du blâme au contrôle. Elles n'excusent pas la tromperie. Elles demandent si la plateforme a rendu la tromperie trop puissante.

La protection des comptes très en vue ne peut pas être un support ordinaire

L'ensemble des comptes concernés a rendu l'incident Twitter particulièrement sensible. Des personnalités publiques très en vue, des entreprises et des comptes liés aux cryptomonnaies ont attiré une énorme attention. Un faux message provenant d'un tel compte n'est pas la même chose qu'un spam provenant d'un profil abandonné. Il peut atteindre les utilisateurs immédiatement, être intégré par les médias, déclencher des transactions automatisées ou des détections d'arnaque, et se propager via des captures d'écran même après suppression.

L'annonce archivée du DOJ selon laquelle trois personnes ont été inculpées pour leur rôle présumé dans le piratage de Twitter documente la réponse des forces de l'ordre. Un communiqué ultérieur du SDNY décrivant une peine de cinq ans de prison pour Joseph James O'Connor montre que l'affaire est restée dans un dossier plus large de cybercriminalité. La responsabilité pénale compte, mais elle ne règle pas la question de la gouvernance de la plateforme. La plateforme devait encore montrer comment les comptes à haut risque seraient protégés contre l'abus des outils internes.

La protection des comptes très en vue devrait inclure plus que des badges ou une visibilité publique. Elle devrait signifier des règles administratives différentes. Un compte sensible pourrait nécessiter une double approbation pour les changements d'e-mail, de numéro de téléphone, de mot de passe, les invalidations de session ou les restrictions de publication. Il pourrait déclencher des alertes plus fortes lorsqu'un outil interne le touche. Il pourrait avoir un chemin de récupération renforcé qui ne peut pas être complété par une seule action de support.

Il pourrait être surveillé pour détecter un langage d'arnaque soudain ou des schémas d'adresses de paiement.

Il y a un compromis. Les équipes de support doivent aider rapidement les propriétaires de comptes, en particulier les journalistes, les responsables et les organisations sous attaque. Des contrôles trop rigides peuvent bloquer les utilisateurs légitimes ou retarder les réparations urgentes. Mais l'incident de 2020 montre pourquoi la commodité du support ordinaire ne peut pas être le seul critère de conception. Un faux message provenant d'un compte très en vue est un événement public.

La même logique s'applique aux captures d'écran internes et à la visibilité des outils. Les reportages de l'époque, y compris la couverture par TechCrunch du piratage de comptes très en vue dans une arnaque aux cryptomonnaies, ont discuté des captures d'écran d'outils internes circulant pendant l'événement. Qu'une capture d'écran particulière ait capturé toute la puissance des outils pertinents est moins important que le principe: les vues administratives elles-mêmes peuvent devenir des artefacts sensibles.

Une plateforme devrait limiter non seulement qui peut utiliser des outils puissants, mais qui peut voir les métadonnées sensibles des comptes et comment les vues d'outils peuvent être exportées, photographiées ou utilisées à mauvais escient.

La protection des comptes très en vue a également besoin d'un mode de réponse publique. Lorsque la plateforme reconnaît que des comptes éminents sont abusés, elle peut avoir besoin de restreindre la publication, verrouiller des comptes, supprimer du contenu dangereux ou désactiver temporairement certaines fonctions. Twitter a effectivement restreint certaines activités de compte pendant l'incident. La question de responsabilité est de savoir si ces contrôles d'urgence étaient prédéfinis, testés et proportionnés, ou improvisés sous pression.

L'atténuation de la fraude s'est produite aussi en dehors de Twitter

Le contenu immédiat était une arnaque aux cryptomonnaies, et une partie de l'atténuation s'est produite en dehors de la plateforme. Coinbase a ensuite indiqué qu'elle avait bloqué plus d'un millier de clients pour envoyer du bitcoin vers l'adresse de l'arnaque. Ce dossier est important car il montre comment les incidents de plateforme créent des devoirs pour les systèmes adjacents. La défaillance du contrôle interne de Twitter est devenue un problème de lutte contre la fraude pour la plateforme d'échange et un problème de protection des utilisateurs.

Le public traite parfois les incidents d'arnaque aux cryptomonnaies comme si les victimes auraient simplement dû savoir mieux. C'est trop simple. La fraude a fonctionné en empruntant la légitimité de comptes déjà reconnus par les utilisateurs. Lorsqu'un attaquant publie via un compte de confiance, le signal de fraude est en partie inversé. Le compte lui-même devient l'appât. Les utilisateurs peuvent encore agir imprudemment, mais la plateforme a contribué à la tromperie en permettant à une fausse déclaration d'apparaître sous une identité de confiance.

La couverture par CNBC du piratage de Twitter et de l'arnaque bitcoin a capturé la rapidité avec laquelle l'événement est devenu une préoccupation publique courante. L'analyse de KrebsOnSecurity sur qui était derrière le piratage a suivi les preuves de la communauté de sécurité et le contexte du commerce de comptes en ligne. Ces rapports ne doivent pas remplacer les dossiers officiels, mais ils montrent à quelle vitesse l'attention publique, l'enquête sur la cybercriminalité et la réponse de la plateforme ont convergé.

L'atténuation de la fraude devrait donc faire partie du playbook d'incident. Si une prise de contrôle de compte de plateforme est utilisée pour solliciter des paiements, la plateforme devrait avoir des voies rapides pour notifier les plateformes d'échange, les sociétés de paiement, les fournisseurs d'analyse de portefeuille, les forces de l'ordre et les équipes de lutte contre les abus. Elle devrait préserver les preuves du contenu publié, des URL, des adresses de paiement, des comptes concernés et du moment. Elle devrait publier des directives claires pour les utilisateurs identifiant l'arnaque sans l'amplifier inutilement.

La plateforme devrait également envisager une détection préconstruite pour les modèles de fraude courants soudains sur les comptes très en vue. Si de nombreux comptes éminents commencent à publier des messages d'adresse de paiement similaires, le schéma de contenu lui-même peut être un signal que les outils internes ou la récupération de compte ont été abusés. La modération automatisée du contenu seule ne suffit pas, mais elle peut réduire l'exposition.

Le dossier de responsabilité ne doit pas prétendre que Twitter contrôlait Coinbase ou d'autres plateformes d'échange. Il doit reconnaître que les incidents de plateforme publique créent une chaîne de défense plus large. L'entreprise qui possède l'outil interne doit coordonner rapidement avec les entreprises qui peuvent arrêter les mouvements d'argent. Cette coordination fait partie de la réduction des dommages publics.

L'avis public devait équilibrer vitesse et preuves

Lors d'une prise de contrôle de plateforme publique, l'avis n'est pas une formalité. Les utilisateurs doivent savoir si les comptes sont authentiques, si les messages doivent être crus, si les messages directs ont pu être consultés, si les propriétaires de comptes doivent agir, et si les attaquants ont encore le contrôle. En même temps, la plateforme peut encore être en train d'enquêter. Le problème de l'avis est d'être rapide sans faire semblant d'avoir des certitudes.

La mise à jour de l'incident de Twitter décrivait les mesures prises, y compris la limitation des fonctionnalités pour de nombreux comptes et le travail pour restaurer l'accès. Elle distinguait également les comptes concernés de l'activité plus large de la plateforme et décrivait les systèmes internes comme faisant partie de l'enquête. Ce type de communication publique est nécessaire car l'incident lui-même se produit en public. Le silence peut permettre aux messages d'arnaque et aux captures d'écran de continuer à circuler comme s'il s'agissait simplement d'un comportement de compte inhabituel.

Le Guide de traitement des incidents de sécurité informatique du NIST est utile car il cadre la communication comme faisant partie de la réponse aux incidents, pas comme un ajout de relations publiques. Dans un incident de parole de plateforme, la communication est aussi un contrôle de sécurité. Un avis clair peut réduire les transferts frauduleux, avertir les utilisateurs de ne pas faire confiance aux messages d'arnaque, rassurer les propriétaires de comptes sur les prochaines étapes et empêcher la désinformation sur l'incident de devenir un second incident.

Un bon avis devrait séparer les faits connus, les actions en cours, les conseils aux utilisateurs et les questions non résolues. Connu: certains comptes ont été compromis via les systèmes internes. Action en cours: certaines fonctionnalités ont été restreintes. Conseils aux utilisateurs: n'envoyez pas de cryptomonnaie et ne vous fiez pas aux messages suspects. Non résolu: ensemble complet des comptes, exposition des messages directs, chemin d'accès interne, et remédiation à long terme. Cette structure aide les utilisateurs à comprendre quoi faire même pendant que les détails évoluent.

La question plus difficile est de savoir si la plateforme devrait conserver un historique visible de l'incident. Les mises à jour publiques peuvent être supprimées, modifiées ou dispersées dans des fils. Une page ou un rapport d'incident durable donne aux utilisateurs, aux propriétaires de comptes, aux chercheurs et aux régulateurs un dossier stable. Pour une plateforme qui sert d'intermédiaire à la communication publique, le dossier de sa propre communication devrait être vérifiable.

L'avis public doit également prendre en compte les propriétaires de comptes dont les noms ont été abusés. Ils ont besoin de confirmation, de soutien et de conseils pour restaurer la confiance avec leurs abonnés. Un propriétaire de compte très en vue peut avoir besoin de dire qu'un message était faux, de coordonner avec les forces de l'ordre, d'avertir ses abonnés et d'évaluer le préjudice réputationnel. L'avis de la plateforme devrait soutenir ce processus, pas simplement protéger la marque de la plateforme.

Les dossiers réglementaires ont exposé le caractère d'infrastructure publique

Le rapport du NYDFS est précieux car il a traité Twitter comme plus qu'une simple application privée. Il a reconnu que les grandes plateformes de médias sociaux peuvent affecter les marchés financiers, la communication politique, la sécurité publique et la confiance civique. Cela ne signifie pas que chaque plateforme doit être réglementée comme une banque. Cela signifie que les contrôles internes méritent d'être examinés lorsque leur défaillance peut fausser la communication publique à grande échelle.

Le Formulaire 10-K 2021 de Twitter incluait un langage de facteur de risque faisant référence au piratage de juillet 2020 et à la possibilité d'incidents de sécurité affectant les comptes et la perception publique. Les dépôts SEC servent les investisseurs, mais dans ce cas, les mêmes faits importent pour les utilisateurs. Une entreprise qui monétise l'attention et la communication publique doit gouverner les systèmes qui décident si l'attention est authentique.

Le communiqué de presse de la FTC de 2022 accusant Twitter d'avoir utilisé de manière trompeuse les données de sécurité des comptes pour la publicité ciblée concernait un sujet différent, et l' ordonnance modifiée de la FTC ne doit pas être traitée comme un rapport technique sur le piratage de juillet 2020. Elle appartient néanmoins au dossier de gouvernance car elle montre comment les régulateurs évaluent les représentations, les programmes de sécurité, les promesses de confidentialité et les contrôles internes autour de la sécurité des comptes. La confiance dans la plateforme ne concerne pas seulement un incident.

Le caractère d'infrastructure publique apparaît dans la charge de la réponse. Si le compte d'une banque est piraté, les clients peuvent être trompés. Si le compte d'un responsable public est piraté, les électeurs peuvent être induits en erreur. Si le compte d'un média est piraté, les informations peuvent être déformées. Si le compte d'un dirigeant d'entreprise est piraté, les marchés peuvent réagir. Si le compte d'une plateforme d'échange de cryptomonnaies est piraté, la fraude peut s'accélérer. Les outils internes de la plateforme se situent en dessous de toutes ces conséquences.

Les régulateurs posent donc des questions auxquelles les utilisateurs ordinaires ne peuvent pas répondre. Combien d'employés avaient accès? Quelle authentification était requise? Les actions privilégiées étaient-elles consignées et examinées? Les comptes très en vue étaient-ils soumis à des contrôles supplémentaires? Les employés étaient-ils formés? Les outils internes étaient-ils conçus pour minimiser les abus? Les restrictions de réponse aux incidents étaient-elles testées? La vérité a-t-elle été dite rapidement aux utilisateurs?

Ces questions ne doivent pas être rejetées comme un regard rétrospectif. Ce sont exactement les questions qu'une plateforme devrait se poser avant un incident. La gouvernance d'une plateforme publique signifie concevoir les opérations internes autour des dommages publics qu'elles peuvent créer.

Les outils de support ont besoin de moindre privilège et de friction

Les outils de support existent pour résoudre les problèmes des utilisateurs. Ils réinitialisent les comptes verrouillés, aident à récupérer l'accès, gèrent les signalements d'abus, examinent le statut des comptes et maintiennent la plateforme utilisable. Ce but légitime les rend puissants. L'incident Twitter montre pourquoi les outils de support ont besoin de moindre privilège et de friction délibérée. Un outil qui peut aider le bon utilisateur peut aussi aider le mauvais attaquant si l'accès et le workflow sont faibles.

Le concept de configuration de base sécurisée de la CISA s'applique ici même s'il s'agit de directives générales. Les outils internes devraient avoir des contrôles de base: accès limité, MFA, vérifications de l'état du dispositif, journalisation, examen, approbation des modifications et séparation des tâches. Pour les comptes particulièrement sensibles, la base devrait être plus stricte. L'objectif de sécurité n'est pas de rendre le support impossible; c'est de rendre les actions de support dangereuses visibles et plus difficiles à abuser.

Le moindre privilège devrait s'appliquer à plusieurs niveaux. Les rôles des employés devraient accorder uniquement les actions de compte nécessaires à un travail. Les fonctions des outils devraient être séparées de sorte que voir les données du compte, modifier les identifiants, changer les informations de contact, désactiver les protections et publier ou restaurer l'accès ne soient pas regroupés à la légère. Les comptes sensibles devraient nécessiter une approbation supplémentaire. L'accès temporaire devrait expirer. Les schémas anormaux devraient déclencher un examen.

La friction n'est pas toujours mauvaise. Dans la conception de produits grand public, la friction est souvent traitée comme un ennemi. Dans les opérations privilégiées, une certaine friction est un contrôle. Un deuxième examinateur, une période de refroidissement, un authentifiant plus fort, un code de motif obligatoire ou une alerte à haut risque peuvent empêcher une attaque d'ingénierie sociale précipitée de devenir un événement public. La clé est d'appliquer la friction là où le dommage le justifie.

Les outils de support ont également besoin d'une observabilité forte. Si une action interne touche un compte très en vue, la plateforme devrait savoir qui l'a faite, depuis quel dispositif, sous quelle session, pour quel ticket, avec quelle approbation et ce qui a changé. Les journaux devraient être protégés contre la falsification et conservés assez longtemps pour l'enquête. Si des actions suspectes se produisent, la plateforme devrait pouvoir reconstruire rapidement la chronologie.

Après l'incident, la question de responsabilité publique est de savoir si ces contrôles ont changé. Une entreprise peut dire qu'elle a limité l'accès ou amélioré les outils, mais les utilisateurs et les régulateurs ont besoin de confiance que la refonte a abordé le mode de défaillance réel. L'accès a-t-il été réduit? L'authentification a-t-elle été renforcée? La surveillance s'est-elle améliorée? Les comptes très en vue ont-ils reçu des protections supplémentaires? La formation à l'ingénierie sociale a-t-elle changé? Les outils de restriction d'urgence sont-ils devenus plus clairs?

L'exposition privée était une question de preuve distincte

Les messages publics étaient le dommage le plus visible, mais la prise de contrôle de compte soulève également une question de preuve plus silencieuse: quel matériel de compte privé a pu être atteint? Les utilisateurs publics ont vu des tweets d'arnaque. Les propriétaires de comptes et les régulateurs ont dû se demander quels messages directs, adresses e-mail, numéros de téléphone, paramètres de compte, état de session, données de récupération et métadonnées internes ont pu être consultés. La réponse importe car le même accès interne qui peut publier publiquement peut aussi exposer des informations privées ou permettre de futures attaques.

Les mises à jour publiques de Twitter distinguaient les comptes utilisés pour publier des questions plus larges d'accès aux comptes, mais les observateurs extérieurs avaient encore besoin de comprendre la limite des preuves. Les attaquants ont-ils consulté les messages directs pour certains comptes concernés? Ont-ils téléchargé des informations de compte? Ont-ils changé les adresses e-mail ou les numéros de téléphone? Ont-ils créé une persistance? Ont-ils utilisé les outils internes uniquement pour réinitialiser ou publier, ou aussi pour inspecter les données privées du compte? Ces questions ne sont pas alarmistes;

elles découlent directement de l'autorité du système interne.

Pour les utilisateurs très en vue, l'exposition privée peut être plus dommageable que l'arnaque publique. Les messages directs d'un journaliste peuvent contenir des informations de source. Le compte d'un responsable public peut inclure une coordination sensible. Le compte d'une entreprise peut contenir des annonces sous embargo, des plaintes de clients ou des contacts de crise. Une célébrité ou un activiste peut faire face à des risques de sécurité personnelle. Une plateforme devrait donc séparer « faux message supprimé » de « exposition privée examinée ». Ce sont des états différents.

Les preuves nécessaires pour l'évaluation de l'exposition privée sont également différentes. Les enquêteurs ont besoin des journaux des outils internes, des journaux d'accès aux comptes, des informations de session, des modifications des données de récupération, de l'activité API, des demandes de données exportées et de tout accès inhabituel aux messages. Ils doivent préserver les enregistrements avant que le nettoyage d'urgence n'efface la piste. Ils doivent en dire assez aux propriétaires de comptes pour agir sans révéler des détails qui aident les attaquants.

L'avis public devrait être étagé. Les utilisateurs ordinaires ont besoin de directives générales. Les propriétaires de comptes concernés ont besoin de conclusions directes et spécifiques. Les propriétaires de comptes particulièrement sensibles peuvent avoir besoin d'un soutien séparé, d'une coordination avec les forces de l'ordre ou de conseils sur la protection des contacts. La plateforme ne doit pas divulguer excessivement les faits privés des comptes au public, mais elle ne doit pas cacher l'incertitude aux personnes qui supportent le risque.

C'est aussi là que l'examen de l'accès interne devient plus qu'une question de RH. Si un outil employé peut exposer des données de compte, et non seulement l'autorité de publication, alors chaque action privilégiée a des conséquences sur la vie privée. L'accès doit être justifié, journalisé et examiné. La conception des outils devrait limiter ce que le personnel de support peut voir à moins qu'une tâche ne l'exige. Les champs sensibles devraient être masqués si possible. Les vues de comptes à haut risque devraient déclencher des signaux d'audit même si aucun message public n'est publié.

La même logique d'exposition privée s'applique après un incident. Il ne suffit pas de demander si les attaquants ont publié. Le message est l'artefact visible. La question plus profonde est de savoir si la surface privée du compte a été touchée. Une plateforme mature devrait être capable de répondre rapidement à cette question, compte par compte, avec suffisamment de confiance pour guider le propriétaire.

La restriction d'urgence est un instrument de contrôle public

L'un des choix les plus difficiles pendant l'incident a été de restreindre les fonctionnalités de la plateforme. Lorsque Twitter a limité l'activité de certains comptes, il utilisait un contrôle d'urgence pour réduire les dommages pendant l'enquête. De tels contrôles sont brutaux. Ils peuvent empêcher d'autres messages d'arnaque, mais ils peuvent aussi faire taire des propriétaires de comptes légitimes lors d'un événement public rapide. Ce compromis est la raison pour laquelle la restriction d'urgence doit être traitée comme un instrument de contrôle public, pas comme un bouton de panique improvisé.

La question de conception est ce qui déclenche la restriction. Un seul compte de célébrité compromis peut nécessiter le verrouillage d'un compte. Un schéma sur de nombreux comptes très en vue peut nécessiter des limites temporaires sur une classe de comptes ou d'actions internes. La preuve que les outils internes sont abusés peut nécessiter la désactivation de certains workflows d'employés. La plateforme a besoin de critères avant l'urgence car l'équipe d'incident prendra autrement des décisions de gouvernance sous une pression extrême.

La deuxième question est la portée. Quels comptes sont restreints? Quelles actions sont bloquées? Les propriétaires de comptes peuvent-ils lire les messages mais pas publier? Peuvent-ils supprimer les messages d'arnaque? Peuvent-ils communiquer via d'autres canaux? Les comptes gouvernementaux, d'urgence, de santé ou de sécurité publique sont-ils traités différemment? La plateforme a-t-elle un moyen d'empêcher les attaquants d'exploiter des comptes à faible visibilité non restreints pendant que les comptes très en vue sont gelés? Une restriction trop étroite peut échouer;

une restriction trop large peut créer des perturbations publiques inutiles.

La troisième question est l'explicabilité. Les utilisateurs devraient savoir quand la plateforme impose des restrictions d'urgence et pourquoi. Les propriétaires de comptes devraient savoir comment reprendre un contrôle de confiance. Le public devrait savoir si les messages suspects doivent être ignorés. Les régulateurs devraient savoir si la restriction a protégé les utilisateurs ou simplement limité les dommages réputationnels. Cela n'exige pas de révéler chaque détail technique. Cela exige un dossier fondé sur des principes.

La restriction d'urgence a également un pendant interne. Si les attaquants utilisent des outils d'employés, l'entreprise peut avoir besoin de restreindre l'accès aux outils, révoquer les sessions, exiger une réauthentification, désactiver des workflows ou forcer une approbation supplémentaire. Ces actions peuvent ralentir le support sur toute la plateforme. Elles peuvent aussi empêcher d'autres dommages. La plateforme devrait être capable de distinguer un ralentissement du service client d'une mesure de confinement nécessaire.

C'est pourquoi le dossier du conseil devrait inclure des verbes de contrôle d'urgence. Détecté, restreint, verrouillé, révoqué, réauthentifié, restauré, inspecté, notifié, non résolu. Chaque verbe dit quelque chose de spécifique. Un conseil qui entend seulement « nous avons répondu rapidement » ne peut pas évaluer si le système de contrôle a fonctionné. Un conseil qui voit les verbes peut demander où du temps a été perdu et quelles capacités n'existaient pas.

L'examen post-incident devrait tester la restriction d'urgence par des exercices. Simulez un abus d'outils internes contre des comptes éminents. Simulez des messages d'arnaque coordonnés sur différentes classes de comptes. Simulez un compromis d'identifiant employé lors d'un événement d'actualité. Demandez qui peut autoriser les restrictions, qui les communique, comment les propriétaires de comptes sont soutenus, comment les partenaires de fraude sont notifiés, comment les journaux sont préservés et comment les restrictions sont levées.

L'exercice devrait impliquer les équipes produit, juridique, politique, ingénierie, confiance et sécurité, support, communication et direction.

L'incident de 2020 a montré que la plateforme pouvait imposer des limites d'urgence, mais la question durable est de savoir si ces limites sont devenues une capacité répétée. Une plateforme qui sert d'intermédiaire à la parole publique a besoin d'outils de confinement aussi soigneusement conçus que les outils de publication. Sinon, la prochaine défaillance de contrôle interne forcera à nouveau l'entreprise à choisir entre vitesse, précision, équité et réduction des dommages en public.

Le propriétaire du compte avait besoin d'un dossier de récupération

Chaque propriétaire de compte dont le compte a été touché avait besoin de plus que la restauration de la capacité de publication. Ils avaient besoin d'un dossier de récupération. Ce dossier devrait dire ce qui est arrivé au compte, quel accès interne ou externe a été observé, quel contenu a été publié ou tenté, quelles données privées ont été ou n'ont pas été consultées, quels paramètres ont changé, quels identifiants ou sessions ont été réinitialisés, quelles protections ont été ajoutées et quelles incertitudes subsistent.

Le dossier de récupération importe car les propriétaires de comptes ont leurs propres parties prenantes. Une entreprise peut avoir besoin de rassurer les clients et les investisseurs. Un responsable public peut avoir besoin de corriger des informations fausses. Un journaliste peut avoir besoin de protéger ses sources. Une personnalité publique peut avoir besoin d'avertir ses abonnés contre les arnaques. Une plateforme d'échange ou un service financier peut avoir besoin de coordonner avec les équipes de lutte contre la fraude. La clôture interne de la plateforme ne donne pas automatiquement à ces parties les preuves dont elles ont besoin.

Le dossier devrait également inclure le timing. Quand le compte a-t-il été touché pour la première fois? Quand le contenu d'arnaque a-t-il été publié? Quand a-t-il été supprimé? Quand le compte a-t-il été verrouillé? Quand le contrôle a-t-il été restauré? Quand le propriétaire a-t-il reçu un avis? Quand les questions d'exposition privée ont-elles été résolues? Le timing fait souvent la différence entre une note d'incident propre et un récit public contesté.

La récupération du propriétaire du compte devrait également être différenciée par risque. Un petit compte utilisé dans l'attaque mérite un soutien, mais un dirigeant national, une grande entreprise, une salle de rédaction, une agence de santé ou une institution financière peut avoir des devoirs en aval différents. La plateforme devrait avoir une voie de réponse pour les comptes sensibles qui fournit une coordination plus directe et de meilleures preuves sans permettre aux utilisateurs puissants de contourner à la légère les règles de sécurité.

Le dossier de récupération protège également la plateforme. Si l'entreprise peut montrer qu'elle a donné des informations spécifiques, précises et opportunes aux propriétaires de comptes concernés, elle est moins vulnérable aux accusations d'avoir minimisé l'incident. Si elle ne peut pas le montrer, les propriétaires de comptes peuvent combler le vide avec des spéculations, des captures d'écran ou des déclarations publiques contradictoires. Les preuves réduisent les rumeurs.

Enfin, le dossier de récupération devrait alimenter la conception du produit. Si de nombreux propriétaires de comptes posent les mêmes questions, ces questions devraient devenir partie du modèle d'incident suivant. Si les propriétaires ne peuvent pas comprendre quels contrôles les protègent, le produit devrait exposer un état de sécurité plus fort. Si les propriétaires de comptes sensibles ont besoin de fonctionnalités que les comptes ordinaires n'ont pas, la plateforme devrait rendre la politique explicite. La récupération n'est pas la fin de l'incident; c'est le début de la refonte.

Un audit utile suivrait une action privilégiée

L'échantillon d'audit le plus simple après l'incident Twitter consisterait à suivre une action de compte privilégiée de la demande à l'exécution. Choisissez un compte sensible. Demandez qui pouvait le voir, qui pouvait modifier les détails de récupération, qui pouvait réinitialiser l'accès, qui pouvait outrepasser les restrictions, quelle approbation était requise, quelles conditions de dispositif et de réseau étaient vérifiées, quels événements de journal étaient générés, qui examinait ces événements et quelle alerte se déclencherait si l'action semblait anormale. Rejouez ensuite la même action sous pression d'ingénierie sociale.

Cet échantillon évite une assurance vague. Il ne demande pas si l'entreprise se soucie de la sécurité. Il demande si une action interne spécifique peut être effectuée en toute sécurité. Si l'action peut être effectuée par un seul employé trompé sans authentification forte, approbation, journalisation et alerte, la plateforme a un écart de contrôle concret. Si l'action nécessite un accès justifié, un deuxième examen, des journaux inviolables et une surveillance post-action, la plateforme a des preuves.

L'audit devrait également échantillonner le refus. Un employé peut-il dire non à une demande suspecte sans pénalité? Le support peut-il escalader rapidement un appel étrange? L'accès d'urgence peut-il être bloqué jusqu'à ce que l'identité soit vérifiée? L'entreprise peut-elle prouver qu'une action privilégiée n'a pas eu lieu? Les preuves de refus comptent car de nombreuses attaques d'ingénierie sociale réussissent en créant de l'urgence et en faisant en sorte que le refus ressemble à un mauvais service client.

Ce type d'audit est étroit, mais c'est exactement là que vit la confiance publique. Le compte public est l'artefact visible. L'action interne privilégiée est la charnière cachée.

La confiance publique devrait être répétée comme la disponibilité

La dernière leçon de Twitter est que les défaillances d'authenticité publique devraient être répétées comme les pannes. Une plateforme devrait s'entraîner à ce qui se passe lorsque les outils internes produisent de fausses paroles publiques: qui gèle les comptes, qui avertit les utilisateurs, qui contacte les plateformes d'échange ou les partenaires de paiement, qui soutient les propriétaires de comptes et qui explique l'incertitude de l'exposition privée. Les exercices de disponibilité protègent l'accessibilité. Les exercices d'authenticité protègent la capacité des utilisateurs à croire le compte visible du tout.

Le test de responsabilité est un contrôle public authentique

La question de responsabilité après le piratage de Twitter en 2020 n'est pas seulement de savoir si les attaquants ont été attrapés ou si les messages d'arnaque ont été supprimés. Elle est de savoir si la plateforme pouvait prouver que l'authenticité publique des comptes reposait sur des contrôles aussi forts que la confiance que les utilisateurs placent dans les comptes visibles. Le système interne devait correspondre à la signification publique des comptes qu'il pouvait modifier.

Le dossier public ne montre pas chaque refonte interne, chaque changement d'accès ou chaque test post-incident. Il montre que l'attaque a exploité une surface interne à fort effet de levier et que les régulateurs, les procureurs, les plateformes d'échange, les journalistes et les utilisateurs ont tous traité l'événement comme plus qu'un abus de compte ordinaire. C'est le cadre correct. Les propres outils de la plateforme sont devenus l'objet de risque.

Pour les plateformes sociales, la leçon est durable. Les systèmes d'administration et de support devraient être conçus comme des systèmes de sécurité publique lorsqu'ils peuvent affecter la parole publique. L'accès des employés devrait être minimisé. Les comptes à haut risque devraient avoir des contrôles spéciaux. La résilience à l'ingénierie sociale devrait être intégrée dans le workflow, pas seulement laissée à la formation. La coordination de la fraude devrait être rapide. L'avis public devrait être structuré et durable. Les rapports post-incident devraient distinguer ce qui est connu, ce qui a changé et ce qui reste incertain.

Pour les utilisateurs, la leçon est inconfortable. Un compte vérifié ou éminent n'est pas la preuve que la personne ou l'organisation nommée a tapé le message. L'authenticité du compte dépend d'une chaîne qui inclut la sécurité de l'utilisateur, les contrôles internes de la plateforme, l'accès des employés, les workflows de récupération et la réponse aux incidents. La majeure partie de cette chaîne est invisible pour les utilisateurs ordinaires. C'est pourquoi la responsabilité de la plateforme importe.

Pour les régulateurs et les conseils, la leçon est de se renseigner sur le plan de contrôle derrière la confiance publique. Qui peut toucher aux comptes éminents? Quelle approbation est requise? Quels journaux existent? Quelles restrictions d'urgence peuvent être appliquées? Quelles défenses contre l'ingénierie sociale protègent les employés? Quels scénarios de dommages publics ont été répétés? Les réponses devraient être des preuves, pas de la confiance dans la marque.

L'incident de Twitter en 2020 devrait être retenu pour l'arnaque, mais pas limité à elle. L'arnaque était le signal visible. Le problème sous-jacent était que l'autorité interne d'une plateforme pouvait être convertie en fausse parole publique. Lorsque cela se produit, la plateforme n'est pas simplement une victime des attaquants. Elle est l'opérateur du système de contrôle dont la défaillance a rendu la tromperie crédible. La communication publique authentique dépend de la gouvernance, des tests et des contraintes de ce système avant que le prochain attaquant n'essaie d'emprunter une voix de confiance.