Resumo

  • O caso da exposição dos números de telefone do Authy é importante porque um aplicativo de autenticação pode se tornar um diretório de segmentação se os controles de exposição de endpoints e de enumeração falharem.
  • Quem tinha o controle prático sobre a exposição dos endpoints do Authy, a enumeração dos números de telefone, os controles de taxa de abuso, as notificações aos usuários, as orientações anti-phishing, as configurações padrão de proteção de contas e a prova de que um aplicativo de autenticação não se tornou um diretório de segmentação?
  • A questão da responsabilidade reside no fato de que um serviço de autenticação armazena dados que os atacantes podem usar para atingir as próprias pessoas que contam com ele para sua proteção, de modo que a prevenção da enumeração e a especificidade das notificações se tornam deveres essenciais de confiança.
  • Os usuários do Authy, as equipes de segurança, os analistas de fraude, os titulares de contas móveis, os desenvolvedores, os reguladores e os compradores de serviços de autenticação precisavam de evidências de que a exposição dos números de telefone foi contida e traduzida em orientações de proteção acionáveis.
  • Este artigo trata os relatórios públicos da divulgação, os documentos de segurança e privacidade da Twilio, a documentação do Authy e do Verify, e as diretrizes de padrões públicos como trilhas de evidências distintas.

Por que este caso pertence a um dossiê sobre riscos e responsabilidade

A Twilio transformou a exposição dos números de telefone do Authy em um teste de responsabilidade por abuso de identidade porque os serviços de autenticação detêm dados de confiança que os atacantes podem reutilizar mesmo sem obter o token secreto em si. Um número de telefone associado a um aplicativo de autenticação não é apenas uma informação de contato. Ele pode se tornar um sinal para phishing, tentativas de SIM-swap, engenharia social, abusos de recuperação de conta, spam direcionado e assédio.

A exposição é particularmente sensível porque a população afetada se autosselecionou: são pessoas que adotaram uma ferramenta de autenticação porque desejavam uma proteção mais forte.

O gatilho público é limitado, mas pesado de consequências. Relatórios públicos descreveram a divulgação da Twilio de que atores maliciosos identificaram dados associados a contas Authy por meio de um endpoint não autenticado. A questão da responsabilidade não se limita a saber se os atacantes obtiveram códigos de autenticação.

Trata-se de saber se o serviço permitiu a enumeração dos números de telefone, como os controles de taxa e a autenticação de endpoints falharam ou foram contornados, com que rapidez a exposição foi contida, com que especificidade os usuários foram informados e se as orientações correspondiam às vias de abuso que decorrem da segmentação de números de telefone. A diferença é importante porque os usuários não podem mudar de número de telefone tão facilmente quanto uma senha.

A página de segurança atual da Twilio emhttps://www.twilio.com/en-us/security, sua página de privacidade emhttps://www.twilio.com/en-us/legal/privacy, sua página de status emhttps://status.twilio.com/, a documentação do Authy emhttps://www.twilio.com/docs/authye a documentação do Verify emhttps://www.twilio.com/docs/verifyfornecem o contexto oficial de como os serviços de identidade, os dados dos usuários e os controles de confiança são apresentados publicamente. Relatórios comohttps://www.bleepingcomputer.com/news/security/twilio-confirms-data-breach-after-hackers-leak-33m-authy-user-phone-numbers/ehttps://www.securityweek.com/twilio-says-hackers-identified-phone-numbers-of-authy-users/fornecem a cronologia pública da divulgação do Authy. Essas fontes devem ser mantidas em trilhas distintas: os documentos da empresa mostram os compromissos de controle públicos e a documentação; os artigos de notícias fornecem reportagem pública contemporânea; as fontes de padrões fornecem o vocabulário de controle.

Este caso pertence a uma série sobre riscos e responsabilidade porque os danos causados pelo abuso de identidade são frequentemente adiados, fragmentados e difíceis de atribuir. Uma lista de números de telefone associada a usuários de um aplicativo de autenticação pode ser usada posteriormente em golpes direcionados. Um usuário pode receber uma mensagem ou chamada convincente sem entender por que foi selecionado. Uma equipe de fraude pode observar um aumento nas tentativas de SIM-swap sem saber qual exposição anterior contribuiu para a segmentação.

Um desenvolvedor que avalia provedores de identidade pode querer saber se o provedor trata a prevenção de enumeração como um controle de primeira classe. O incidente imediato é apenas uma parte do dossiê. O problema permanente é saber se as evidências públicas permitem que os usuários e as organizações reduzam os abusos posteriores.

Um aplicativo de autenticação pode se tornar uma superfície de segmentação

Os aplicativos de autenticação são comercializados e adotados como ferramentas defensivas. Esse enquadramento geralmente é justo: os códigos baseados em aplicativo podem reduzir o risco de roubo de senha e alguns modelos de phishing. Mas as ferramentas defensivas sempre coletam metadados, e esses metadados podem se tornar úteis para os atacantes. Um número de telefone associado a uma conta Authy fornece informações sobre o usuário.

Sugere que o número pode estar vinculado a contas protegidas por autenticação multifator, que o usuário pode depender de uma identidade móvel e que um cenário de engenharia social pode ser adaptado a um contexto de autenticação.

O problema de responsabilidade, portanto, não se limita à tomada de controle de conta. Se os atacantes enumerarem os números de telefone associados a um serviço de autenticação, talvez não precisem dos tokens de autenticação para causar danos. Eles podem enviar mensagens de phishing se passando pelo serviço, tentar SIM-swap junto às operadoras, segmentar os fluxos de recuperação de conta em outros serviços ou construir listas para futuros ataques de credenciais. A página do MITRE sobre coleta de informações telefônicas de vítimas emhttps://attack.mitre.org/techniques/T1589/002/e sua página sobre a técnica de phishing emhttps://attack.mitre.org/techniques/T1566/não constituem conclusões específicas sobre o Authy. Elas fornecem o vocabulário público que explica por que os dados de contato expostos podem se tornar material de segmentação operacional.

É por isso que a especificidade das notificações é importante. Se uma empresa apenas diz aos usuários que seus números de telefone foram expostos, eles podem entender isso como um problema de privacidade. Se a empresa explicar as vias de abuso prováveis, os usuários podem tratar isso como um problema de segurança: desconfiar de mensagens com tema Authy, reforçar a proteção da conta da operadora, examinar as configurações de recuperação de conta, verificar as mensagens pelos canais oficiais e alertar as equipes de suporte de que os atacantes podem fazer referência ao aplicativo de autenticação.

O mesmo fato pode produzir um comportamento de proteção diferente dependendo de como é apresentado.

Um provedor de serviços de autenticação tem controle prático sobre a autenticação de endpoints, limitação de taxa, detecção de abusos, registro em log, notificações públicas, orientações de atualização do aplicativo e configurações padrão que reduzem o risco após a exposição. Os usuários têm controle prático sobre a segurança de seus dispositivos, a resposta a phishing, os PINs de operadora quando disponíveis e a higiene de recuperação de conta. As equipes de segurança têm controle sobre o treinamento de funcionários, os scripts de suporte e os alertas.

Mas todos esses controles a jusante dependem das primeiras evidências do provedor: o que foi exposto, por qual período, por meio de que tipo de endpoint e quais abusos foram observados ou são plausíveis.

O caso Authy é, portanto, um caso de fronteira de confiança. Os usuários confiavam no serviço para ajudá-los a proteger outras contas. O serviço também detinha dados que podiam ajudar os atacantes a identificar esses usuários. A responsabilidade consiste em se perguntar se o dossiê público da Twilio tornou esse papel duplo suficientemente claro para que usuários e compradores pudessem agir.

A exposição de um endpoint é uma falha de governança antes de ser uma manchete

Um endpoint não autenticado não é simplesmente um erro de codificação. Em um serviço de identidade, é uma falha de governança porque significa que um caminho acessível ao público expôs dados de associação sensíveis sem a devida comprovação de autorização, controle de taxa ou resistência a abusos. A entrada da CWE sobre ausência de autenticação emhttps://cwe.mitre.org/data/definitions/306.htmle a restrição incorreta de tentativas excessivas de autenticação emhttps://cwe.mitre.org/data/definitions/307.htmlfornecem um vocabulário de controle útil. Elas não decidem o que aconteceu internamente na Twilio. Elas mostram por que essa classe de problemas pertence a um dossiê de responsabilidade.

A governança de endpoints deve responder a perguntas básicas antes de um incidente. Quais endpoints revelam se um objeto de identidade existe? Quais endpoints podem ser consultados em grande escala? Quais endpoints retornam respostas diferentes para usuários válidos e inválidos? Quais endpoints expõem dados de contato, dados de contato mascarados, a presença de uma conta, o status do dispositivo ou pistas de recuperação? Quais controles detectam padrões de enumeração? Quais logs são mantidos por tempo suficiente para reconstituir a escala?

Quais equipes de produto são proprietárias da decisão de tornar um endpoint público, autenticado, limitado por taxa ou descontinuado?

Se essas perguntas não forem respondidas antes da exposição, elas se tornam muito mais difíceis depois. Um provedor pode ser capaz de fechar rapidamente o endpoint, mas ainda tem dificuldade em provar quantos registros foram consultados, se o tráfego de ataque foi completo ou parcial, quais usuários foram afetados e se endpoints relacionados foram abusados. Essa incerteza se torna um custo público. Os usuários precisam saber se estão pessoalmente expostos a riscos posteriores. As equipes de segurança precisam saber se devem alertar os funcionários. Os reguladores precisam entender a falha de controle e a extensão do incidente.

Os compradores precisam de evidências de que o inventário de endpoints e a detecção de abusos do serviço mudaram.

O material do OWASP sobre segurança de API com relação ao consumo irrestrito de recursos emhttps://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/é relevante porque a enumeração muitas vezes depende da escala. Uma única consulta pode parecer inofensiva. Milhões de consultas podem transformar um serviço em um diretório. A questão de governança é se o serviço trata a própria escala como um sinal de risco. Limites de taxa, detecção de anomalias, requisitos de autenticação, padronização de respostas e bloqueios de abuso não são suplementos opcionais para metadados de identidade. Eles fazem a diferença entre uma função de pesquisa e um canal de extração.

O dossiê público de responsabilidade deve, portanto, evitar uma conclusão estreita do tipo "endpoint corrigido". Um endpoint corrigido informa aos usuários que o caminho conhecido foi fechado. Não lhes diz se o provedor examinou endpoints vizinhos, alterou as regras de revisão de design, melhorou os controles de taxa, testou a enumeração ou atualizou o registro em log. Para um serviço de autenticação, a correção deve atingir o processo que permitiu a exposição do endpoint.

A notificação aos usuários deve traduzir a exposição em proteção

A notificação aos usuários só é útil se alterar o que os usuários e as equipes de segurança podem fazer. Para a exposição dos números de telefone do Authy, uma notificação acionável distinguiria vários fatos. Ela diria se os tokens de autenticação, as senhas de conta, os dados de partida, os backups ou os segredos do dispositivo foram envolvidos. Ela diria quais dados de contato ou associação de conta foram expostos. Ela identificaria os riscos posteriores prováveis: phishing, smishing, segmentação de SIM-swap, personificação do suporte do Authy e abuso de recuperação de conta em outros serviços.

Ela recomendaria medidas de proteção que os usuários podem tomar realisticamente.

As orientações anti-phishing da CISA emhttps://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks, suas orientações MFA "Secure Our World" emhttps://www.cisa.gov/secure-our-world/turn-mfae suas orientações sobre senhas emhttps://www.cisa.gov/secure-our-world/use-strong-passwordsmostram a base de referência pública para orientações de ação. O objetivo não é que cada usuário afetado precise de um programa de segurança. O objetivo é que a notificação relacione os dados expostos a uma lista de ações curta e realista. Um usuário que apenas fica sabendo que "seu número de telefone pode ter sido exposto" pode não fazer nada. Um usuário que fica sabendo que "os atacantes podem agora se passar pelo Authy ou pela sua operadora; não compartilhe códigos; verifique as mensagens pelos canais oficiais; proteja sua conta móvel" tem mais chances de reduzir os danos.

A notificação também deve respeitar a carga dos usuários. Dizer aos usuários para "permanecerem vigilantes" é fraco quando o provedor pode dar conselhos mais precisos. A vigilância é uma responsabilidade sem controle. Conselhos melhores nomeiam comportamentos específicos a não seguir, configurações específicas a verificar e canais de suporte específicos a usar. Eles também explicam o que o provedor já fez: remoção do endpoint, atualizações do aplicativo, monitoramento de abusos, alterações no controle de taxa, atualizações forçadas quando aplicável e notificação adicional se novos abusos surgirem.

As equipes de segurança precisam de uma versão diferente da notificação. Se os funcionários usam o Authy para suas contas profissionais, a equipe de segurança precisa saber se deve emitir alertas internos, monitorar phishing com tema Authy, atualizar os scripts de suporte, examinar usuários de alto risco e solicitar que operadoras ou proprietários de contas reforcem os processos de recuperação. Uma notificação voltada ao consumidor pode não ser suficiente para as equipes de risco empresarial.

Os provedores de serviços de identidade devem presumir que uma exposição que afeta autenticadores tem consequências organizacionais, mesmo que os campos de dados sejam limitados.

Por fim, a notificação deve preservar a incerteza sem se esconder atrás dela. Se a Twilio não sabia se todos os números de telefone consultados foram usados posteriormente, poderia dizê-lo. Se tinha evidências de que apenas a associação de números de telefone estava envolvida, poderia dizer quais evidências sustentam esse limite. Se recomendava atualizações do aplicativo, poderia explicar se a atualização era necessária para a contenção ou apenas para defesa em profundidade. Os usuários não precisam de uma falsa certeza. Eles precisam de um dossiê de decisão.

Os números de telefone são difíceis de mudar e fáceis de transformar em armas

Um número de telefone não é uma senha. Ele está integrado em contas de operadoras, registros bancários, aplicativos de mensagens, fluxos de trabalho de atendimento ao cliente, fluxos de recuperação, contatos familiares, arquivos públicos e sistemas governamentais ou profissionais. Quando um número de telefone associado a um aplicativo de autenticação é exposto, a resposta disponível para o usuário é limitada. Ele não pode simplesmente clicar em "redefinir número de telefone" em todos os aspectos de sua vida. Isso torna a prevenção e a notificação mais importantes do que a transferência de carga após o ocorrido.

Os riscos posteriores são bem conhecidos. As orientações da FTC sobre SIM-swap emhttps://consumer.ftc.gov/articles/sim-swap-scams-how-protect-yourselfe as orientações da FCC sobre fraude telefônica emhttps://www.fcc.gov/consumers/guides/cell-phone-fraudsão recursos de proteção ao consumidor, mesmo que alguns sites públicos possam aplicar proteção por robô para acesso automatizado. Elas mostram por que a exposição de números móveis pertence a um dossiê sobre abuso de identidade. Os atacantes que conhecem o número e a postura de segurança de um alvo podem tentar convencer uma operadora, um suporte ou o próprio alvo.

As diretrizes de identidade digital do NIST emhttps://pages.nist.gov/800-63-3/sp800-63b.htmltambém são relevantes porque os autenticadores, os canais fora de banda e a recuperação de conta têm propriedades de garantia diferentes. Novamente, este artigo não usa o NIST como uma conclusão sobre a Twilio. Ele usa o NIST para explicar por que os números de telefone e os sistemas de autenticação devem ser gerenciados com cuidado. Um número de telefone pode ser um identificador conveniente, mas a conveniência não o torna de baixo risco quando vinculado a uma presença de serviço de autenticação.

A norma de responsabilidade deve perguntar como o design do provedor minimizou a exposição dos números de telefone antes do evento. Os números de telefone eram retornados apenas quando necessário? As respostas eram padronizadas para evitar o teste de presença de conta? Os endpoints eram autenticados? As tentativas de enumeração eram limitadas por taxa e detectadas? Os logs eram suficientes para notificar com precisão os usuários afetados? Os princípios de minimização de dados foram aplicados aos fluxos de trabalho de suporte, análise e produto? A privacidade e a segurança se encontram nesse ponto.

Menos metadados desnecessários são expostos, menor é o diretório de segmentação que os atacantes podem construir.

Os usuários podem e devem tomar medidas de proteção, mas a ação do usuário não apaga a responsabilidade do provedor. Uma empresa que opera um aplicativo de autenticação tem um dever maior de evitar tornar os usuários mais fáceis de serem alvo. Se sua resposta pública se baseia principalmente em dizer aos usuários para monitorarem mensagens suspeitas, o dossiê está incompleto. Ela também deve explicar o que mudou internamente no serviço para reduzir a probabilidade de que os dados de contato dos usuários possam ser novamente enumerados.

Os compradores de serviços de autenticação precisam de evidências, não de reasseguramento

As empresas, os desenvolvedores e as organizações regulamentadas que avaliam serviços de autenticação precisam de evidências de que o serviço trata a prevenção de abusos como um requisito de produto. Eles não podem confiar apenas em uma página de confiança, uma visão geral de segurança ou uma política de privacidade geral.

Esses documentos são importantes, mas a responsabilidade dos compradores exige evidências mais específicas: inventários de endpoints, controles de taxa de abuso, monitoramento, revisão de segurança de APIs públicas, manuais de notificação de incidentes, limites de retenção de dados e configurações padrão que reduzem a exposição do usuário.

A documentação da API Verify da Twilio emhttps://www.twilio.com/docs/verify/api, a visão geral do Verify emhttps://www.twilio.com/docs/verifye a explicação da autenticação de dois fatores emhttps://www.twilio.com/docs/glossary/what-is-two-factor-authentication-2famostram o contexto de produto no qual os serviços de identidade são comprados e integrados. A documentação do Authy emhttps://www.twilio.com/docs/authymostra o contexto legado e de produto para o uso da autenticação. Essas páginas não respondem a todas as perguntas sobre o incidente. Elas ajudam os compradores a entender quais superfícies e suposições precisam ser examinadas após uma exposição.

O dossiê de responsabilidade dos compradores deve perguntar se o provedor pode fornecer uma narrativa de controle clara. Quais elementos de dados são necessários para a autenticação? Quais são opcionais? Quais são expostos em caminhos de suporte ou API? Quais endpoints podem confirmar a existência de uma conta? Quais sinais de abuso são monitorados? O que acontece quando uma enumeração é detectada? Como os usuários são notificados? O provedor pode produzir rapidamente uma lista de usuários afetados? Qual caminho de atualização do aplicativo ou configuração existe se um controle precisar ser alterado?

Os compradores também devem perguntar como o provedor separa as evidências de status das evidências de segurança. Uma página de status de serviço pode indicar se os produtos estão operacionais. Ela pode não dizer se um endpoint foi abusado para enumeração. A página de status da Twilio emhttps://status.twilio.com/é útil para transparência operacional, mas incidentes de segurança exigem especificidade adicional. Se um evento de segurança não degrada a disponibilidade, ele ainda pode degradar a confiança. O dossiê público de responsabilidade não deve forçar os leitores a confundir disponibilidade com garantia de segurança.

Por fim, os compradores precisam saber como o provedor apoia a comunicação a jusante. Se uma empresa usa os serviços de identidade Authy ou Twilio para seus clientes ou funcionários, ela pode precisar de sua própria notificação, scripts de suporte e avaliação de risco. Um provedor que fornece apenas declarações genéricas enfraquece esse trabalho a jusante. Um provedor que fornece fatos delimitados, vias de abuso, controles recomendados e compromissos de acompanhamento ajuda os compradores a proteger os mesmos usuários cuja confiança estava em jogo.

Os controles de abuso devem ser medidos como controles operacionais

A prevenção de abusos é frequentemente discutida como uma função de segurança, mas neste caso é um controle operacional. A autenticação de endpoints, os limites de taxa, a detecção de anomalias, a padronização de respostas, as defesas contra bots, o registro em log e os alertas decidem se um produto pode ser consultado até expor dados. Eles também decidem se o provedor pode reconstituir o que aconteceu. Se uma empresa não consegue medir abusos, ela não consegue notificar com precisão.

Os controles CIS emhttps://www.cisecurity.org/controlse o Cybersecurity Framework do NIST emhttps://www.nist.gov/cyberframeworkfornecem um vocabulário de alto nível útil para inventário de ativos, registro em log, monitoramento, controle de acesso, resposta a incidentes e melhoria. Eles não substituem um dossiê específico do provedor. O dossiê específico do provedor deve dizer como a exposição do endpoint do Authy foi fechada, quais superfícies adjacentes foram examinadas, quais alterações de controle de taxa foram feitas, quais sinais detectarão futuras enumerações e quais evidências provocariam uma nova notificação.

Os controles de abuso também devem ser testados em relação à realidade econômica. Os atacantes podem distribuir as consultas, desacelerar, rotacionar a infraestrutura e misturar a enumeração com tráfego legítimo. Um simples limite de taxa pode não ser suficiente se as respostas válidas e inválidas diferirem em tempo, mensagem ou estrutura. Um serviço maduro testa a resistência à enumeração como parte da segurança do produto, e não apenas durante a resposta a incidentes. Para serviços de autenticação, a privacidade da presença da conta é uma funcionalidade, não um luxo.

O problema da evidência é que muitos desses controles são invisíveis para os usuários. Os usuários não podem inspecionar inventários de endpoints ou lógicas de limitação de taxa. Essa invisibilidade aumenta o dever de divulgação do provedor. A notificação pública não precisa revelar limites de detecção sensíveis, mas pode descrever as categorias de controles e os compromissos de reparação. Ela pode dizer se o endpoint foi removido ou autenticado, se o monitoramento de abusos foi expandido, se os usuários afetados foram notificados, se atualizações do aplicativo foram recomendadas e se categorias de dados adicionais foram excluídas.

O risco de evidências fracas é a repetição. Se o dossiê público se limita a "corrigimos o endpoint", a próxima avaliação não terá base para julgar se o sistema de controle melhorou. Se o dossiê identifica as categorias de controles que mudaram, os futuros compradores, reguladores e usuários poderão cobrar do provedor um padrão mais elevado sem precisar do código-fonte privado. É para isso que servem as evidências de responsabilidade.

A localidade dos dados e a privacidade moldam as consequências

O manifesto inclui a soberania dos dados e a localidade porque os serviços de identidade operam entre jurisdições, operadoras, usuários, aplicativos, provedores e sistemas de suporte. Uma exposição de números de telefone não é apenas um problema técnico de API. É também um problema de dados pessoais. Usuários de diferentes jurisdições podem ter expectativas de notificação diferentes, os reguladores podem fazer perguntas diferentes e os compradores empresariais podem precisar entender onde os dados da conta são processados ou mantidos. Um serviço global não pode tratar a localidade como uma reflexão posterior quando a exposição ocorre.

A página de privacidade da Twilio emhttps://www.twilio.com/en-us/legal/privacyé relevante porque faz parte da promessa pública sobre o tratamento de dados pessoais. A página de segurança emhttps://www.twilio.com/en-us/securityé relevante porque enquadra os controles de confiança. Mas o dossiê público do incidente deve vincular esses compromissos gerais à categoria de dados expostos. Quais dados estavam associados às contas Authy? A exposição foi limitada a números de telefone ou incluía identificadores de conta, metadados de dispositivo, indicadores de status ou outros campos? Os usuários afetados foram notificados em todas as jurisdições? As decisões de retenção e minimização de dados foram examinadas? Processadores ou sistemas de suporte estavam envolvidos?

A responsabilidade pela privacidade não deve ser reduzida a saber se os dados expostos eram "sensíveis" no sentido jurídico estrito. Os números de telefone vinculados à presença de um aplicativo de autenticação são sensíveis no sentido prático de segurança porque podem apoiar a segmentação. É por isso que o artigo usa uma linguagem de abuso de identidade. Os mesmos dados podem ser comuns em um contexto e de alto risco em outro. Um número de telefone em um diretório profissional público é diferente de um número de telefone em uma lista de usuários de autenticador.

A questão da localidade também afeta a resposta organizacional. Uma multinacional cujos funcionários usam Authy pode precisar coordenar notificações, comunicações com comitês de empresa, avaliações de reguladores e orientações ao suporte. Um usuário consumidor pode precisar de orientações específicas da operadora. Um desenvolvedor pode precisar decidir se identificadores baseados em número de telefone são apropriados para seu próprio produto. Um bom dossiê público apoia todas essas decisões ao esclarecer a categoria de exposição e as vias de abuso.

O teste de responsabilidade chave é se a linguagem da privacidade e a linguagem da segurança se encontram. A privacidade explica quais dados são detidos e como podem ser usados. A segurança explica como os abusos são prevenidos e contidos. Em uma exposição do Authy, ambos os dossiês devem convergir sobre os mesmos fatos: quais dados foram expostos, por que o endpoint existia, como a enumeração era possível, o que mudou e o que os usuários devem fazer.

A recuperação de identidade é um problema operacional a jusante

A exposição de números de telefone se torna custosa porque o trabalho de recuperação recai sobre muitas organizações que não compartilham um único plano de controle. A Twilio pode controlar o endpoint Authy e as orientações do aplicativo. Uma operadora controla a fricção do SIM-swap, os PINs de conta, os processos de portabilidade e o comportamento do atendimento ao cliente. Um banco controla seus próprios alertas de login e regras de recuperação de conta. Um empregador controla a verificação do suporte. Um consumidor controla as mensagens em que confiar e as contas a examinar.

O usuário exposto é frequentemente a única pessoa que precisa coordenar todos esses lugares. É por isso que a notificação do provedor não pode se limitar a uma declaração estreita de campo de dados.

Uma notificação de recuperação útil deve dizer aos usuários e organizações que tipo de trabalho a jusante é proporcionado. Se apenas a associação de números de telefone foi exposta, os usuários podem não precisar redefinir todas as suas contas. Eles podem precisar tratar mensagens com tema Authy como suspeitas, evitar compartilhar códigos, verificar as configurações de segurança da operadora, examinar métodos de recuperação de conta de alto valor e dizer aos suportes internos para não confiarem em chamadores que façam referência ao aplicativo de autenticação como prova de legitimidade.

Esse é um manual diferente do de uma comprometimento de token secreto, e a notificação deve esclarecer a diferença.

Essa distinção é importante para as equipes de segurança. Se o número de telefone de um funcionário aparece em uma lista de usuários de autenticador, o empregador pode precisar monitorar engenharia social contra suporte de TI, folha de pagamento, atendimento ao cliente ou recuperação de contas privilegiadas. O atacante não precisa vencer o autenticador diretamente se puder convencer um funcionário do suporte a redefinir o fator, cadastrar um novo dispositivo ou aprovar uma solicitação de recuperação arriscada. O número de telefone se torna um acessório de confiança em um cenário social.

É por isso que as orientações anti-abuso devem alcançar as equipes de suporte e fraude, não apenas os usuários individuais do aplicativo.

O mesmo problema aparece para desenvolvedores e proprietários de produtos que constroem fluxos de identidade baseados em número de telefone. Se eles usam um número de telefone como identificador estável, canal de recuperação e sinal de risco ao mesmo tempo, então uma exposição em um serviço pode criar pressão em outro. Um usuário visado após a divulgação do Authy pode enfrentar golpes em serviços que não têm ligação direta com o Authy.

O dossiê de responsabilidade deve, portanto, levar os compradores a examinar suas próprias suposições: se os números de telefone são excessivamente utilizados, se as respostas de presença de conta podem ser enumeradas, se os scripts de suporte dependem excessivamente do conhecimento do chamador e se mudanças de alto risco exigem uma prova mais forte.

Há também um problema de timing. Os abusos de identidade nem sempre ocorrem imediatamente após a divulgação. As listas podem ser copiadas, revendidas, enriquecidas e reutilizadas meses depois. Uma declaração pública de que nenhuma comprometimento imediato de conta foi observada pode ser precisa, mas incompleta como guia de proteção. Os usuários precisam saber que a segmentação diferida é plausível quando dados de contato são expostos. As equipes de segurança precisam saber por quanto tempo manter os alertas ativos.

Os provedores devem dizer se o monitoramento continua após o primeiro aviso e se atualizarão os usuários se novos padrões de abuso surgirem.

É aqui que a responsabilidade difere das relações públicas de incidente. Um instinto de relações públicas pode preferir reduzir o evento o mais rápido possível. Um dossiê de responsabilidade reduz o que pode ser reduzido enquanto preserva o risco que permanece. Pode dizer que os segredos de autenticação não foram considerados expostos, ao mesmo tempo que diz que a segmentação de números de telefone cria um risco real de consequências. Pode dizer que o endpoint foi fechado, ao mesmo tempo que diz que os usuários devem tratar mensagens não solicitadas como suspeitas.

Pode dizer que a empresa não tem conhecimento de certos abusos, ao mesmo tempo que explica o que monitorará posteriormente.

O ônus da recuperação também deve ser medido. Quantos usuários foram notificados? Quantas notificações retornaram ou falharam? Usuários de alto risco ou clientes empresariais receberam orientações adicionais? As atualizações do aplicativo foram realmente instaladas? As equipes de suporte viram um aumento nas solicitações? Os canais de denúncia de abuso receberam relatos de phishing com tema Authy? As operadoras ou equipes de fraude receberam indicadores que poderiam ajudá-las a proteger os usuários afetados?

Alguns desses fatos podem permanecer privados, mas um provedor maduro deve saber quais métricas mostrariam se as orientações alcançaram as pessoas que deveriam proteger.

Para os usuários, a expectativa justa não é a perfeição. É um caminho claro. Eles não devem ter que deduzir de blogs de segurança esparsos o que significa a exposição de um número de telefone de um aplicativo de autenticação. Eles devem receber uma explicação delimitada do que foi exposto, do que não foi, dos abusos a esperar, das ações úteis, das ações inúteis e de onde encontrar atualizações. Para as empresas, a expectativa justa é um dossiê do provedor que pode ser transformado em orientações internas sem inventar fatos ausentes.

Se as evidências do provedor não podem sustentar isso, as organizações a jusante reagirão insuficientemente ou excessivamente, e ambos os resultados transferem o custo do proprietário do serviço para as pessoas que dependem dele.

O mesmo dossiê deve manter as evidências visíveis ao cliente após o primeiro ciclo de notícias. Se um usuário relata posteriormente uma tentativa de SIM-swap, uma mensagem de phishing ou uma chamada de suporte suspeita, o provedor e a organização do usuário precisam de uma maneira de vincular esse relato à janela de exposição sem exagerar a causalidade. Isso requer identificadores de incidente, datas de notificação, categorias de dados, orientações sobre a versão do aplicativo e um roteamento de denúncias de abuso que permaneçam disponíveis após a correção do endpoint. Um ticket técnico fechado não é suficiente.

Os abusos de identidade podem se manifestar lentamente, e o dossiê de responsabilidade deve permanecer útil quando os danos a jusante aparecem após o provedor já ter declarado a remediação concluída.

Como seriam evidências melhores

Evidências melhores começariam pelo escopo do endpoint. Elas nomeariam, no nível do produto, a função que permitia consultar dados associados à conta, se a autenticação era necessária, como o abuso foi detectado, como o endpoint foi fechado ou modificado e se endpoints vizinhos foram examinados. Elas não precisariam divulgar detalhes de exploração que criam novos riscos. Elas deveriam dar informações suficientes para que usuários e compradores entendam a classe de falha.

Evidências melhores separariam então os dados expostos dos dados não expostos. Se os tokens de autenticação, segredos de backup, senhas ou acesso à conta não estavam envolvidos, o dossiê deveria dizer quais evidências sustentam esse limite. Se números de telefone ou dados de associação de conta estavam envolvidos, o dossiê deveria dizer quantos usuários foram afetados, qual período foi examinado e qual nível de confiança se aplica à contagem. O objetivo não é envergonhar o provedor. É evitar que usuários e equipes de segurança tenham que adivinhar.

Evidências melhores também traduziriam o risco em ação. Os usuários deveriam saber de quais mensagens desconfiar, se devem atualizar o aplicativo, se devem examinar as configurações de múltiplos dispositivos, se devem reforçar as contas de operadora, se devem estar atentos a phishing com tema Authy e se outras notificações virão. As equipes de segurança deveriam receber orientações distintas para treinamento de funcionários e abuso de suporte. Os desenvolvedores e compradores deveriam receber lições de controle sobre inventário de endpoints, resistência à enumeração e minimização de dados.

Por fim, evidências melhores definiriam a reparação. A reparação não está concluída quando um endpoint é fechado. A reparação inclui um inventário de endpoints examinado, controles de taxa de abuso, melhorias no registro em log, alertas, notificação de usuários, orientações de atualização do aplicativo e uma declaração de acompanhamento se novas evidências alterarem a avaliação de risco. Para um serviço de autenticação, a reparação também significa provar que o produto não se tornou um diretório de segmentação duradouro.

Esse é o padrão que o caso deve deixar. Os serviços de autenticação merecem confiança apenas quando podem mostrar como protegem os metadados em torno da autenticação, e não apenas o segredo de autenticação em si.

Arquivo de evidências para o leitor

O artigo utiliza as seguintes fontes públicas como arquivo de leitura para a exposição dos números de telefone do Authy da Twilio, abuso de endpoint não autenticado, orientações ao cliente, confiança em aplicativos de autenticação e dossiê de responsabilidade por abuso de identidade. As páginas da empresa são tratadas como evidências dos compromissos de controle públicos e do contexto do produto. Os artigos de notícias são usados para a cronologia e o contexto de divulgação pública. As normas e orientações governamentais fornecem vocabulário de controle e contexto de proteção ao usuário, e não conclusões sobre os sistemas privados da Twilio.

Este arquivo de evidências é deliberadamente mais amplo do que uma única notificação porque a responsabilidade dos aplicativos de autenticação cruza o design de endpoints, a minimização de dados de contato, a detecção de abusos, as orientações aos usuários, o risco de phishing, a recuperação de número móvel e a resposta das equipes de segurança. O dossiê público deve apoiar usuários individuais, compradores empresariais, equipes de fraude, desenvolvedores, equipes de privacidade e reguladores.

Perguntas para a revisão do conselho

Uma revisão do conselho deve começar pela propriedade do endpoint. Quem aprovou o endpoint que expunha os dados associados à conta? Quem examinou sua exigência de autenticação, o design da resposta e os controles de taxa? Quem monitorou as tentativas de enumeração? Quem decidiu quando o endpoint deveria ser fechado ou modificado? Quem confirmou que endpoints vizinhos não poderiam ser abusados da mesma forma?

A revisão deve então focar na notificação. Quem decidiu o que foi dito aos usuários? A notificação explicava a diferença entre exposição de número de telefone e comprometimento de token de autenticação? Fornecia medidas de proteção realistas? Apoiava equipes de segurança empresarial bem como usuários individuais? Explicava o que a Twilio havia mudado e o que permanecia incerto?

A revisão deve verificar se os controles anti-abuso melhoraram após o evento. Os inventários de endpoints foram atualizados? As respostas de presença de conta foram padronizadas? Os limites de taxa e as defesas contra bots foram examinados? Os logs e alertas eram suficientes para detectar futuras enumerações? As decisões de minimização de privacidade foram reexaminadas para números de telefone e dados de associação de conta? As vias de abuso relacionadas a operadoras e phishing foram integradas nas orientações?

Para este caso específico, a revisão deve responder diretamente à pergunta do manifesto: Quem tinha o controle prático sobre a exposição dos endpoints do Authy, a enumeração dos números de telefone, os controles de taxa de abuso, a notificação dos usuários, as orientações anti-phishing, as configurações padrão de proteção de contas e a prova de que um aplicativo de autenticação não se tornou um diretório de segmentação?

A resposta deve incluir datas, classes de endpoints, proprietários de controle, evidências de notificação de usuários, mudanças no monitoramento de abusos, incerteza não resolvida e a prova de que a reparação atingiu a fronteira de confiança da qual os usuários dependiam.