Кратко

  • Случай с раскрытием номеров телефонов Authy важен, потому что приложение для аутентификации может превратиться в справочник для таргетирования, если откажут контроль экспозиции endpoint и защита от перебора.
  • Кто фактически контролировал экспозицию endpoint Authy, перебор номеров телефонов, контроль частоты запросов, уведомление пользователей, рекомендации по защите от фишинга, настройки защиты аккаунтов по умолчанию и доказательства того, что приложение для аутентификации не стало справочником для таргетирования?
  • Вопрос подотчётности в том, что сервис аутентификации хранит данные, которые злоумышленники могут использовать для атак на тех самых людей, которые рассчитывают на его защиту; поэтому предотвращение перебора и конкретность уведомлений становятся ключевыми обязанностями доверия.
  • Пользователям Authy, службам безопасности, аналитикам мошенничества, владельцам мобильных аккаунтов, разработчикам, регуляторам и покупателям сервисов аутентификации нужны были доказательства того, что утечка номеров телефонов локализована и переведена в практические рекомендации по защите.
  • Эта статья рассматривает публичные сообщения о раскрытии, материалы Twilio о безопасности и конфиденциальности, документацию Authy и Verify, а также публичные стандарты как отдельные линии доказательств.

Почему этот случай относится к досье о рисках и подотчётности

Twilio превратила раскрытие номеров телефонов Authy в проверку на подотчётность в сфере злоупотреблений идентификацией, потому что сервисы аутентификации хранят доверенные данные, которые злоумышленники могут использовать повторно, даже если они не получили сам секретный токен. Номер телефона, привязанный к приложению для аутентификации, — это не просто контактная информация. Он может стать сигналом для фишинга, попыток подмены SIM-карты, социальной инженерии, злоупотреблений при восстановлении доступа, таргетированного спама и домогательств.

Утечка особенно чувствительна, потому что пострадавшая аудитория выбрала себя сама: это люди, которые начали пользоваться инструментом аутентификации, потому что хотели более сильной защиты.

Публичный триггер узок, но значим. В публичных сообщениях описывалось раскрытие Twilio: злоумышленники определили данные, связанные с аккаунтами Authy, через неаутентифицированный endpoint. Вопрос подотчётности не сводится к тому, получили ли злоумышленники коды аутентификации. Важно, позволял ли сервис перебор номеров телефонов, как отказали или были обойдены контроль частоты запросов и аутентификация endpoint, как быстро утечку локализовали, насколько конкретно уведомили пользователей и соответствовали ли рекомендации тем способам злоупотреблений, которые следуют из таргетирования по номеру телефона.

Разница важна, потому что пользователь не может сменить номер телефона так же легко, как пароль.

Текущая страница безопасности Twilio наисточник: twilio.com, страница конфиденциальности наисточник: twilio.com, страница статуса наисточник: status.twilio.com, документация Authy наисточник: twilio.comи документация Verify наисточник: twilio.comдают официальный контекст того, как публично представлены сервисы идентификации, пользовательские данные и контроль доверия. Такие материалы, какисточник: bleepingcomputer.comиисточник: securityweek.com, дают публичную хронологию раскрытия Authy.

Эти источники следует держать в отдельных линиях: материалы компании показывают публичные обязательства по контролю и документацию; сообщения СМИ — современную событию публичную информацию; источники по стандартам — словарь контрольных мер.

Этот случай относится к серии о рисках и подотчётности, потому что вред от злоупотреблений идентификацией часто отсрочен, фрагментирован и плохо поддаётся атрибуции. Список номеров телефонов, связанных с пользователями приложения для аутентификации, может быть использован позже в таргетированных мошеннических схемах. Пользователь может получить убедительное сообщение или звонок, не понимая, почему выбрали именно его. Команда по борьбе с мошенничеством может увидеть всплеск попыток подмены SIM-карты, не зная, какая предыдущая утечка повлияла на выбор цели.

Разработчик, оценивающий поставщиков идентификационных решений, может захотеть понять, рассматривает ли поставщик предотвращение перебора как первоочередную меру контроля. Поэтому сам инцидент — лишь часть досье.

Постоянный вопрос в том, позволяют ли публичные доказательства пользователям и организациям снизить последующие злоупотребления.

Приложение для аутентификации может стать поверхностью для таргетирования

Приложения для аутентификации продаются и принимаются как защитные инструменты. Такая трактовка в целом справедлива: коды в приложении могут снизить риск кражи паролей и некоторых схем фишинга. Но защитные инструменты тоже собирают метаданные, и эти метаданные могут оказаться полезными злоумышленникам. Номер телефона, связанный с аккаунтом Authy, кое-что говорит о пользователе. Он указывает на то, что номер может быть привязан к аккаунтам, защищённым многофакторной аутентификацией, что пользователь может полагаться на мобильную идентификацию и что сценарий социальной инженерии можно адаптировать под контекст аутентификации.

Поэтому вопрос подотчётности не ограничивается захватом аккаунта. Если злоумышленники переберут номера телефонов, связанные с сервисом аутентификации, им могут не понадобиться токены аутентификации, чтобы причинить вред. Они могут рассылать фишинговые сообщения от имени сервиса, пытаться подменить SIM-карту через операторов, атаковать процессы восстановления доступа в других сервисах или собирать списки для последующих атак на учётные данные. Страница MITRE о сборе информации о телефоне жертвы наисточник: attack.mitre.orgи страница о технике фишинга наисточник: attack.mitre.orgне являются конкретными выводами об Authy.

Они дают публичный словарь для понимания того, почему раскрытые контактные данные могут стать операционным материалом для таргетирования.

Именно поэтому важна конкретность уведомлений. Если компания сообщает пользователям только о том, что номера телефонов были раскрыты, пользователи могут воспринять это как проблему конфиденциальности. Если компания объясняет вероятные пути злоупотреблений, пользователи могут отнестись к этому как к проблеме безопасности: с подозрением относиться к сообщениям от имени Authy, усилить защиту аккаунта у оператора, пересмотреть настройки восстановления доступа, проверять сообщения через официальные каналы и предупредить службу поддержки, что злоумышленники могут ссылаться на приложение для аутентификации.

Один и тот же факт может привести к разному защитному поведению в зависимости от того, как он подан.

Поставщик сервиса аутентификации фактически контролирует аутентификацию endpoint, ограничение частоты запросов, обнаружение злоупотреблений, журналирование, публичные уведомления, рекомендации по обновлению приложения и настройки по умолчанию, снижающие риск после утечки. Пользователи фактически контролируют безопасность устройства, реакцию на фишинг, PIN-коды оператора там, где они доступны, и гигиену восстановления доступа. Службы безопасности контролируют обучение сотрудников, сценарии службы поддержки и оповещения.

Но все эти последующие меры зависят от первого доказательства со стороны поставщика: что было раскрыто, в какое окно, через какой тип endpoint и какое злоупотребление наблюдалось или вероятно.

Поэтому случай Authy — это случай границы доверия. Пользователи доверили сервису защиту других аккаунтов. При этом сервис хранил данные, которые могли помочь злоумышленникам идентифицировать этих пользователей. Подотчётность спрашивает, сделал ли публичный послужной список Twilio эту двойную роль достаточно ясной, чтобы пользователи и покупатели могли действовать.

Экспозиция endpoint — это управленческий сбой ещё до того, как он станет заголовком

Неаутентифицированный endpoint — это не просто ошибка в коде. В сервисе идентификации это управленческий сбой, потому что публичный путь раскрывал чувствительные данные о связях без надлежащего доказательства авторизации, контроля частоты запросов или защиты от злоупотреблений. Запись CWE об отсутствии аутентификации наисточник: cwe.mitre.orgи запись о неправомерном ограничении чрезмерных попыток аутентификации наисточник: cwe.mitre.orgдают полезный словарь контрольных мер. Они не определяют, что произошло внутри Twilio. Они показывают, почему этот класс проблем относится к досье о подотчётности.

Управление endpoints должно давать ответы на базовые вопросы ещё до инцидента. Какие endpoints раскрывают, существует ли объект идентификации? Какие endpoints можно опрашивать в массовом масштабе? Какие endpoints возвращают разные ответы для действительных и недействительных пользователей? Какие endpoints раскрывают контактные данные, маскированные контактные данные, наличие аккаунта, состояние устройств или подсказки для восстановления? Какие контроли обнаруживают паттерны перебора? Какие журналы хранятся достаточно долго, чтобы восстановить масштаб?

Какие продуктовые команды отвечают за решение сделать endpoint публичным, аутентифицированным, ограниченным по частоте или выведенным из эксплуатации?

Если на эти вопросы не ответили до утечки, после неё ответить на них гораздо труднее. Поставщик может быстро закрыть endpoint, но всё равно с трудом доказать, сколько записей было запрошено, была ли атакующая активность полной или частичной, какие пользователи затронуты и не были ли задействованы смежные endpoints. Эта неопределённость становится публичной ценой. Пользователям нужно знать, грозит ли им лично последующий риск. Службам безопасности нужно знать, стоит ли предупреждать сотрудников. Регуляторам нужно понять сбой контроля и его масштаб.

Покупателям нужны доказательства того, что реестр endpoints сервиса и обнаружение злоупотреблений изменились.

Материалы OWASP по безопасности API о неограниченном потреблении ресурсов наисточник: owasp.orgуместны, потому что перебор часто зависит от масштаба. Один запрос может выглядеть безобидно. Миллионы запросов могут превратить сервис в справочник. Вопрос управления в том, рассматривает ли сервис сам масштаб как сигнал риска. Ограничение частоты, обнаружение аномалий, требования к аутентификации, нормализация ответов и ограничения против злоупотреблений — не необязательные дополнения для метаданных идентификации. Это разница между функцией проверки и каналом извлечения.

Поэтому публичное досье о подотчётности должно избегать узкого финала «endpoint исправлен». Исправленный endpoint говорит пользователям, что известный путь закрыт. Он не говорит им, проверил ли поставщик соседние endpoints, изменил ли правила проектирования, улучшил ли контроль частоты запросов, протестировал ли защиту от перебора или обновил журналирование. Для сервиса аутентификации исправление должно дойти до процесса, который допустил экспозицию endpoint.

Уведомление пользователей должно превращать утечку в защиту

Уведомление пользователей полезно только тогда, когда оно меняет то, что пользователи и службы безопасности могут сделать. Для утечки номеров телефонов Authy пригодное уведомление должно различать несколько фактов. Оно должно сообщать, были ли затронуты токены аутентификации, пароли аккаунтов, данные сидов, резервные копии или секреты устройств. Оно должно сообщать, какие контактные данные или данные о связях аккаунта были раскрыты. Оно должно обозначить вероятные последующие риски: фишинг, смишинг, таргетирование для подмены SIM-карты, выдачу себя за поддержку Authy и злоупотребления при восстановлении доступа в других сервисах.

Оно должно рекомендовать защитные шаги, которые пользователи реально могут предпринять.

Рекомендации CISA по фишингу наисточник: cisa.gov, руководство по MFA в рамках Secure Our World наисточник: cisa.govи рекомендации по паролям наисточник: cisa.govпоказывают публичный базовый уровень для руководства к действию. Дело не в том, что каждому затронутому пользователю нужен курс по безопасности. Дело в том, что уведомление должно связывать раскрытые данные с коротким реалистичным списком действий. Пользователь, узнавший только «ваш номер телефона мог быть раскрыт», может ничего не сделать. Пользователь, узнавший «злоумышленники могут теперь выдавать себя за Authy или вашего оператора; не передавайте коды; проверяйте сообщения через официальные каналы; защитите свой мобильный аккаунт», имеет больше шансов снизить вред.

Уведомление также должно учитывать нагрузку на пользователя. Говорить пользователям «будьте бдительны» — слабо, когда поставщик может дать более точные рекомендации. Бдительность — это ответственность без контроля. Лучшие рекомендации называют конкретные поведения, которым не стоит доверять, конкретные настройки для проверки и конкретные каналы поддержки. Они также объясняют, что поставщик уже сделал: удаление endpoint, обновления приложения, мониторинг злоупотреблений, изменение контроля частоты запросов, принудительные обновления там, где это уместно, и дополнительные уведомления, если появится новое злоупотребление.

Службам безопасности нужна другая версия уведомления. Если сотрудники используют Authy для рабочих аккаунтов, служба безопасности должна знать, стоит ли выпускать внутренние предупреждения, отслеживать фишинг под видом Authy, обновлять сценарии службы поддержки, проверять пользователей из группы высокого риска и просить операторов или владельцев аккаунтов усилить процедуры восстановления. Потребительского уведомления может не хватить корпоративным командам по рискам. Поставщики сервисов идентификации должны исходить из того, что утечка, затрагивающая аутентификаторы, имеет организационные последствия, даже если набор полей ограничен.

Наконец, уведомление должно сохранять неопределённость, не прячась за ней. Если Twilio не знала, были ли позже использованы все перебранные номера телефонов, она могла так и сказать. Если у неё были доказательства того, что затронута только связь номеров с аккаунтами, она могла сообщить, какие доказательства поддерживают эту границу. Если она рекомендовала обновить приложение, она могла объяснить, было ли обновление обязательным для локализации или только для многоуровневой защиты. Пользователям не нужна ложная уверенность. Им нужны материалы для принятия решения.

Номера телефонов трудно сменить и легко использовать как оружие

Номер телефона — это не пароль. Он встроен в аккаунты операторов, банковские записи, мессенджеры, процессы поддержки клиентов, процедуры восстановления, семейные контакты, публичные реестры и государственные или рабочие системы. Когда раскрыт номер телефона, связанный с приложением для аутентификации, возможности пользователя ограничены. Он не может просто «сбросить номер телефона» во всех сферах своей жизни. Поэтому предотвращение и уведомление важнее, чем перекладывание ответственности задним числом.

Последующие риски хорошо известны. Руководство FTC по схемам подмены SIM-карты наисточник FTCи руководство FCC о мошенничестве с мобильными телефонами наисточник FCC— это ресурсы по защите потребителей, даже если некоторые публичные сайты применяют защиту от ботов для автоматического доступа. Они показывают, почему раскрытие мобильного номера относится к досье о злоупотреблениях идентификацией. Злоумышленники, знающие номер цели и её защитный профиль, могут попытаться убедить оператора, службу поддержки или саму цель.

Руководство NIST по цифровой идентификации наисточник: pages.nist.govтакже уместно, потому что аутентификаторы, внеполосные каналы и восстановление доступа имеют разные гарантийные свойства. Опять же, эта статья не использует NIST как вывод о Twilio. Она использует NIST, чтобы показать, почему с номерами телефонов и системами аутентификации нужно обращаться осторожно. Номер телефона может быть удобным идентификатором, но удобство не делает его низкорисковым, когда он связан с присутствием в сервисе аутентификации.

Стандарт подотчётности должен спрашивать, как дизайн поставщика минимизировал раскрытие номеров телефонов до события. Возвращались ли номера телефонов только при необходимости? Были ли ответы нормализованы, чтобы предотвратить проверку наличия аккаунта? Были ли endpoints аутентифицированы? Ограничивались ли и обнаруживались ли попытки перебора? Хватало ли журналов для точного уведомления затронутых пользователей? Применялись ли принципы минимизации данных в поддержке, аналитике и продуктовых процессах? В этой точке сходятся конфиденциальность и безопасность.

Чем меньше ненужных метаданных раскрыто, тем меньший справочник для таргетирования смогут построить злоумышленники.

Пользователи могут и должны принимать защитные меры, но действия пользователя не стирают ответственность поставщика. Компания, которая работает с приложением для аутентификации, несёт повышенную обязанность не делать пользователей более лёгкой целью. Если её публичный ответ сводится в основном к совету пользователям следить за подозрительными сообщениями, досье неполно. Она должна также объяснить, что изменилось внутри сервиса, чтобы снизить вероятность повторного перебора пользовательских контактных данных.

Покупателям сервисов аутентификации нужны доказательства, а не заверения

Предприятия, разработчики и организации из регулируемых отраслей, оценивающие сервисы аутентификации, нуждаются в доказательствах того, что сервис рассматривает предотвращение злоупотреблений как требование к продукту. Они не могут полагаться только на страницу доверия, обзор безопасности или общую политику конфиденциальности.

Эти материалы важны, но подотчётность перед покупателем требует более конкретных доказательств: реестров endpoints, контроля частоты запросов, мониторинга, проверок безопасности публичных API, сценариев уведомления об инцидентах, границ хранения данных и настроек по умолчанию, снижающих раскрытие пользовательских данных.

Документация Verify API наисточник: twilio.com, обзор Verify наисточник: twilio.comи объяснение 2FA наисточник: twilio.comпоказывают продуктовый контекст, в котором покупаются и интегрируются сервисы идентификации. Документация Authy наисточник: twilio.comпоказывает унаследованный и продуктовый контекст использования аутентификации. Эти страницы не отвечают на все вопросы об инциденте. Они помогают покупателям понять, какие поверхности и допущения нужно проверить после утечки.

Досье подотчётности покупателя должно спрашивать, может ли поставщик дать ясный рассказ о контроле. Какие элементы данных необходимы для аутентификации? Какие необязательны? Какие раскрываются через поддержку или пути API? Какие endpoints могут подтвердить существование аккаунта? Какие сигналы злоупотреблений отслеживаются? Что происходит при обнаружении перебора? Как уведомляются пользователи? Как быстро поставщик может составить список затронутых пользователей? Какой путь обновления приложения или конфигурации существует, если контроль приходится менять?

Покупатели также должны спрашивать, как поставщик отделяет доказательства статуса сервиса от доказательств безопасности. Страница статуса сервиса может сообщать, работают ли продукты. Она может не сообщать, был ли endpoint использован для перебора. Страница статуса Twilio наисточник: status.twilio.comполезна для операционной прозрачности, но инциденты безопасности требуют дополнительной конкретики. Если событие безопасности не снижает доступность сервиса, оно всё равно может подорвать доверие. Публичное досье не должно заставлять читателей путать доступность с гарантией безопасности.

Наконец, покупателям нужно знать, как поставщик поддерживает последующие коммуникации. Если компания использует Authy или сервисы идентификации Twilio для клиентов или сотрудников, ей могут понадобиться собственные уведомления, сценарии поддержки и оценка рисков. Поставщик, дающий только общие заявления, ослабляет такую работу. Поставщик, предоставляющий конкретные факты, пути злоупотреблений, рекомендуемые меры контроля и обязательства по дальнейшим действиям, помогает покупателям защищать тех самых пользователей, чьё доверие было поставлено на карту.

Контроль злоупотреблений следует оценивать как операционные меры

Предотвращение злоупотреблений часто обсуждается как функция безопасности, но в этом случае это операционная мера контроля. Аутентификация endpoint, ограничение частоты запросов, обнаружение аномалий, нормализация ответов, защита от ботов, журналирование и оповещение определяют, можно ли превратить продукт в утечку через массовые запросы. Они также определяют, может ли поставщик восстановить, что произошло. Если компания не может измерить злоупотребления, она не может уведомить с точностью.

CIS Controls наисточник: cisecurity.orgи NIST Cybersecurity Framework наисточник: nist.govдают полезную общую терминологию для инвентаризации активов, журналирования, мониторинга, управления доступом, реагирования на инциденты и улучшений. Они не заменяют запись конкретного поставщика. Такая запись должна сообщать, как была закрыта экспозиция endpoint Authy, какие смежные поверхности проверены, какие изменения внесены в контроль частоты запросов, какие сигналы обнаружат будущий перебор и какие доказательства привели бы к новому уведомлению.

Меры контроля злоупотреблений также должны проверяться с учётом экономической реальности. Злоумышленники могут распределять запросы, замедляться, менять инфраструктуру и смешивать перебор с легитимным трафиком. Простого лимита частоты может не хватить, если действительные и недействительные ответы различаются по времени, тексту или структуре. Поэтому зрелый сервис тестирует устойчивость к перебору как часть безопасности продукта, а не только во время реагирования на инциденты. Для сервисов аутентификации конфиденциальность наличия аккаунта — это функция, а не роскошь.

Проблема доказывания в том, что многие из этих мер невидимы для пользователей. Пользователи не могут проверить реестры endpoints или логику ограничения частоты. Эта невидимость повышает обязанность поставщика раскрывать информацию. Публичное уведомление не обязано раскрывать чувствительные пороги обнаружения, но оно может описать категории мер и обязательства по исправлению. Оно может сообщить, был ли endpoint удалён или аутентифицирован, расширен ли мониторинг злоупотреблений, уведомлены ли затронутые пользователи, рекомендованы ли обновления приложения и исключены ли дополнительные категории данных.

Риск слабых доказательств — повторение. Если публичная запись заканчивается на «мы исправили endpoint», следующая проверка не имеет оснований судить, улучшилась ли система контроля. Если запись называет изменившиеся категории контроля, будущие покупатели, регуляторы и пользователи смогут требовать от поставщика более высокого стандарта, не нуждаясь в приватном исходном коде. Для этого и нужны доказательства подотчётности.

Локализация данных и конфиденциальность формируют последствия

Этот материал включает суверенитет и локализацию данных, потому что сервисы идентификации работают через юрисдикции, операторов, пользователей, приложения, поставщиков и системы поддержки. Утечка номеров телефонов — не только техническая проблема API. Это также проблема персональных данных. Пользователи в разных юрисдикциях могут иметь разные ожидания от уведомлений, регуляторы могут задавать разные вопросы, а корпоративным покупателям может понадобиться понимать, где обрабатываются или хранятся данные аккаунтов. Глобальный сервис не может относиться к локализации как к второстепенному вопросу после утечки.

Страница конфиденциальности Twilio наисточник: twilio.comуместна, потому что она часть публичного обещания об обработке персональных данных. Страница безопасности наисточник: twilio.comуместна, потому что она описывает контроль доверия. Но публичное досье об инциденте должно связывать эти широкие обязательства с раскрытой категорией данных. Какие данные были связаны с аккаунтами Authy? Ограничивалась ли утечка номерами телефонов или включала идентификаторы аккаунтов, метаданные устройств, статусные флаги или другие поля? Были ли уведомлены затронутые пользователи во всех юрисдикциях? Были ли пересмотрены решения о хранении и минимизации данных? Были ли затронуты обработчики данных или системы поддержки?

Ответственность за конфиденциальность не должна сводиться к вопросу, были ли раскрытые данные «чувствительными» в узком юридическом смысле. Номера телефонов, связанные с присутствием в приложении для аутентификации, чувствительны в практическом смысле безопасности, потому что они могут поддерживать таргетирование. Поэтому статья использует язык злоупотреблений идентификацией. Одни и те же данные могут быть обычными в одном контексте и высокорисковыми в другом. Номер телефона в публичном бизнес-справочнике отличается от номера телефона в списке пользователей аутентификатора.

Вопрос локализации также влияет на реакцию организаций. Многонациональной компании, сотрудники которой используют Authy, может понадобиться координировать уведомления, коммуникации с производственным советом, оценки регуляторов и инструкции для поддержки. Потребителю может понадобиться совет с учётом конкретного оператора. Разработчику может понадобиться решить, уместны ли идентификаторы на основе номеров телефонов в его собственном продукте. Хорошая публичная запись поддерживает все эти решения, делая ясными категорию утечки и пути злоупотреблений.

Ключевой тест подотчётности — встречаются ли язык конфиденциальности и язык безопасности. Конфиденциальность объясняет, какие данные хранятся и как они могут использоваться. Безопасность объясняет, как предотвращаются и локализуются злоупотребления. В случае Authy две записи должны сходиться на одних фактах: какие данные были раскрыты, зачем существовал endpoint, как стал возможен перебор, что изменилось и что делать пользователям.

Восстановление идентичности — это операционная проблема на последующих этапах

Утечка номеров телефонов становится дорогой, потому что работа по восстановлению распределена между многими организациями, у которых нет единой системы контроля. Twilio может контролировать endpoint Authy и рекомендации по приложению. Оператор контролирует барьеры при подмене SIM-карты, PIN-коды аккаунта, процессы переноса номера и поведение поддержки. Банк контролирует собственные оповещения о входе и правила восстановления доступа. Работодатель контролирует проверку в службе поддержки. Потребитель контролирует, каким сообщениям доверять и какие аккаунты проверить.

Пострадавший пользователь часто — единственный человек, которому приходится координировать все эти места. Поэтому уведомление поставщика не может ограничиваться узким заявлением о полях данных.

Полезное уведомление о восстановлении должно говорить пользователям и организациям, какая последующая работа пропорциональна. Если раскрыта только связь номера с аккаунтом, пользователям может не понадобиться сбрасывать каждый аккаунт. Им может понадобиться относиться с подозрением к сообщениям от имени Authy, не передавать коды, проверить настройки безопасности у оператора, пересмотреть методы восстановления доступа к ценным аккаунтам и сказать внутренней службе поддержки не доверять звонящим, которые ссылаются на приложение для аутентификации как на доказательство легитимности.

Это другой сценарий, чем компрометация секретного токена, и уведомление должно ясно показывать разницу.

Это различие важно для служб безопасности. Если номер телефона сотрудника есть в списке пользователей аутентификатора, работодателю может понадобиться следить за социальной инженерией против ИТ-поддержки, расчётов зарплаты, поддержки клиентов или восстановления привилегированных аккаунтов. Злоумышленнику не нужно побеждать аутентификатор напрямую, если он может убедить сотрудника поддержки сбросить фактор, зарегистрировать новое устройство или одобрить рискованный запрос на восстановление. Номер телефона становится средством убеждения в социальном сценарии.

Поэтому рекомендации по борьбе со злоупотреблениями должны доходить до служб поддержки и команд по мошенничеству, а не только до отдельных пользователей приложения.

Та же проблема появляется у разработчиков и владельцев продуктов, которые строят процессы идентификации на основе номеров телефонов. Если они используют номер телефона одновременно как стабильный идентификатор, канал восстановления и сигнал риска, утечка в одном сервисе может создать давление в другом. Пользователь, ставший целью после раскрытия Authy, может столкнуться с мошенничеством в сервисах, не имеющих прямого отношения к Authy.

Поэтому досье подотчётности должно подталкивать покупателей к проверке собственных допущений: не злоупотребляют ли они номерами телефонов, можно ли перебрать ответы о наличии аккаунта, не слишком ли сильно сценарии поддержки полагаются на знания звонящего и требуют ли изменения с высоким риском более сильных доказательств.

Есть и проблема времени. Злоупотребления идентификацией не всегда происходят сразу после раскрытия. Списки могут копироваться, перепродаваться, обогащаться и использоваться повторно месяцами позже. Публичное заявление о том, что немедленной компрометации аккаунтов не наблюдалось, может быть точным и всё же неполным как рекомендация по защите. Пользователям нужно знать, что отсроченное таргетирование вероятно, когда раскрыты контактные данные. Службам безопасности нужно знать, как долго держать предупреждения активными.

Поставщикам нужно сообщать, продолжается ли мониторинг после первого уведомления и обновят ли они пользователей при появлении новых схем злоупотреблений.

Здесь подотчётность отличается от PR по инциденту. PR-инстинкт может предпочитать как можно быстрее сузить событие. Запись подотчётности сужает то, что можно сузить, сохраняя остающийся риск. Она может сказать, что секреты аутентификации не были раскрыты, и одновременно сказать, что таргетирование по номеру телефона создаёт реальный последующий риск. Она может сказать, что endpoint закрыт, и одновременно — что пользователям следует относиться к нежелательным сообщениям с подозрением. Она может сказать, что компания не знает об определённых злоупотреблениях, и объяснить, что она будет отслеживать дальше.

Нагрузку по восстановлению тоже нужно измерять. Сколько пользователей было уведомлено? Сколько уведомлений не было доставлено или вернулось? Получили ли пользователи из группы высокого риска или корпоративные клиенты дополнительные рекомендации? Были ли обновления приложения реально установлены? Увеличилось ли число обращений в поддержку? Поступали ли в каналы сообщений о злоупотреблениях жалобы на фишинг под видом Authy? Получили ли операторы или команды по мошенничеству индикаторы, которые помогли бы защитить затронутых пользователей?

Некоторые из этих фактов могут остаться приватными, но зрелый поставщик должен знать, какие метрики показали бы, дошла ли рекомендация до людей, которых она должна была защитить.

Для пользователей справедливое ожидание — не совершенство, а понятный путь. Им не следует выводить из разрозненных блогов о безопасности, что означает утечка номеров телефонов из приложения для аутентификации. Они должны получить ограниченное объяснение того, что было раскрыто, что нет, каких злоупотреблений ожидать, какие действия полезны, какие не нужны и где искать обновления. Для предприятий справедливое ожидание — файл поставщика, который можно превратить во внутренние инструкции, не выдумывая недостающие факты.

Если доказательства поставщика не могут этого обеспечить, нижестоящие организации будут либо недооценивать, либо переоценивать риск, и оба исхода переносят издержки с владельца сервиса на людей, которые на него полагаются.

Тот же файл должен сохранять ориентированные на клиента доказательства и после первого новостного цикла. Если пользователь позже сообщит о попытке подмены SIM-карты, фишинговом сообщении или подозрительном звонке в поддержку, поставщик и организация пользователя должны иметь возможность связать это сообщение с окном утечки, не преувеличивая причинность. Для этого нужны идентификаторы инцидента, даты уведомлений, категории данных, рекомендации по версиям приложения и маршрутизация сообщений о злоупотреблениях, которые остаются доступными после исправления endpoint. Закрытого технического тикета недостаточно.

Злоупотребления идентификацией могут проявляться медленно, и запись подотчётности должна оставаться полезной, когда последующий вред появляется после того, как поставщик уже объявил об устранении последствий.

Как выглядели бы лучшие доказательства

Лучшие доказательства начались бы с области действия endpoint. Они назвали бы на уровне продукта функцию, которая позволяла запрашивать данные, связанные с аккаунтом, требовалась ли аутентификация, как обнаруживались злоупотребления, как endpoint был закрыт или изменён и были ли проверены соседние endpoints. Для этого не нужно раскрывать детали эксплуатации, создающие новый риск. Нужно дать пользователям и покупателям достаточно информации, чтобы понять класс сбоя.

Затем лучшие доказательства отделили бы раскрытые данные от нераскрытых. Если токены аутентификации, секреты резервных копий, пароли или доступ к аккаунтам не были затронуты, запись должна сообщить, какие доказательства поддерживают эту границу. Если были затронуты номера телефонов или данные о связях аккаунтов, запись должна сообщить, сколько пользователей пострадало, какой период проверен и какова степень уверенности в этом числе. Цель — не пристыдить поставщика. Цель — перестать заставлять пользователей и службы безопасности гадать.

Лучшие доказательства также переводили бы риск в действия. Пользователи должны знать, каким сообщениям не доверять, нужно ли обновлять приложение, проверять ли настройки нескольких устройств, усиливать ли защиту аккаунта у оператора, быть ли настороже к фишингу под видом Authy и последуют ли новые уведомления. Службы безопасности должны получать отдельные рекомендации для обучения сотрудников и защиты от злоупотреблений в службе поддержки. Разработчики и покупатели должны получать уроки контроля: реестр endpoints, устойчивость к перебору и минимизация данных.

Наконец, лучшие доказательства определили бы устранение. Устранение не завершается закрытием endpoint. Оно включает проверенный реестр endpoints, контроль частоты запросов, улучшения журналирования, оповещение, уведомление пользователей, рекомендации по обновлению приложения и последующее заявление, если новые доказательства изменят оценку риска. Для сервиса аутентификации устранение также означает доказательство того, что продукт не превратился в долговременный справочник для таргетирования.

Такой стандарт и должен оставить после себя этот случай. Сервисы аутентификации заслуживают доверия, только когда они показывают, как защищают метаданные вокруг аутентификации, а не только сам секрет аутентификации.

Досье источников для читателя

Статья использует следующие публичные источники в качестве досье по раскрытию номеров телефонов Authy, злоупотреблению неаутентифицированным endpoint, рекомендациям пользователям, доверию к приложению для аутентификации и записи подотчётности при злоупотреблениях идентификацией. Страницы компании рассматриваются как доказательство публичных обязательств по контролю и продуктового контекста. Сообщения СМИ используются для хронологии и контекста публичного раскрытия. Стандарты и правительственные рекомендации дают словарь контроля и контекст защиты пользователей, а не выводы о частных системах Twilio.

Это досье намеренно шире одного уведомления, потому что подотчётность приложения для аутентификации охватывает проектирование endpoints, минимизацию контактных данных, обнаружение злоупотреблений, рекомендации пользователям, фишинговый риск, восстановление мобильных номеров и реакцию служб безопасности. Публичная запись должна поддерживать отдельных пользователей, корпоративных покупателей, команды по борьбе с мошенничеством, разработчиков, команды по конфиденциальности и регуляторов.

Вопросы для совета директоров

Проверка совета директоров должна начаться с владения endpoint. Кто утвердил endpoint, раскрывший данные, связанные с аккаунтом? Кто проверял требования к его аутентификации, дизайн ответов и контроль частоты запросов? Кто отслеживал попытки перебора? Кто решал, когда endpoint следует закрыть или изменить? Кто подтвердил, что соседние endpoints нельзя использовать таким же образом?

Затем проверка должна изучить уведомление. Кто решал, что сказать пользователям? Объясняло ли уведомление разницу между утечкой номеров телефонов и компрометацией токенов аутентификации? Давало ли оно реалистичные шаги защиты? Поддерживало ли оно корпоративные службы безопасности так же, как отдельных пользователей? Объясняло ли оно, что Twilio изменила и что осталось неопределённым?

Проверка должна проверить, улучшились ли меры контроля злоупотреблений после события. Были ли обновлены реестры endpoints? Были ли нормализованы ответы о наличии аккаунта? Были ли пересмотрены лимиты частоты запросов и защита от ботов? Достаточно ли журналов и оповещений для обнаружения будущего перебора? Были ли пересмотрены решения о минимизации номеров телефонов и данных о связях аккаунтов? Были ли пути злоупотреблений через операторов и фишинг включены в рекомендации?

В этом конкретном случае проверка должна прямо ответить на ключевой вопрос этого досье: кто фактически контролировал экспозицию endpoint Authy, перебор номеров телефонов, контроль частоты запросов, уведомление пользователей, рекомендации по защите от фишинга, настройки защиты аккаунтов по умолчанию и доказательства того, что приложение для аутентификации не стало справочником для таргетирования?

Ответ должен включать даты, классы endpoints, владельцев контроля, доказательства уведомления пользователей, изменения в мониторинге злоупотреблений, нерешённую неопределённость и доказательства того, что устранение достигло границы доверия, на которую рассчитывали пользователи.