Кратко

  • Инцидент с подбором учётных данных в PayPal, уведомление пользователей, раскрытие идентификационных данных, сброс учётных записей и вопрос подотчётности в отношении восстановления прав потребителей.
  • PayPal раскрыл факт несанкционированного доступа к клиентским учётным записям через подбор учётных данных, показав, как повторное использование паролей может порождать вопросы подотчётности платформы в части обнаружения, ограничения, уведомления и восстановления.
  • Кто фактически контролировал обнаружение подбора учётных данных, ограничение числа попыток входа, сброс учётных записей, содержание уведомлений, объём затронутых полей, мониторинг мошенничества и доказательства того, что восстановление прав пользователей соответствовало риску злоупотребления учётными записями?
  • Проблема подотчётности в том, что подбор учётных данных — это поведение злоумышленника, но платформа по-прежнему контролирует пороги обнаружения, фрикцию, уведомления, доказательства восстановления и путь поддержки для пострадавших пользователей.
  • Потребителям, малым продавцам, антифрод-командам, регуляторам, операторам платёжных платформ, банкам и менеджерам по идентификационным рискам нужны были доказательства того, что злоупотребление учётными записями было локализовано и устранено, а не просто списано на повторное использование паролей.

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

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

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

Открытые материалы о PayPal необычно полезны, потому что Департамент финансовых услуг Нью-Йорка (NYDFS) позже включил этот инцидент в регуляторное предписание. Пресс-релиз DFS по адресуисточник: dfs.ny.govи соглашение о мерах принудительного характера по адресуисточник: dfs.ny.govописывают событие в области кибербезопасности в декабре 2022 года, связанное с подбором учётных данных, раскрытием незамаскированной информации из формы 1099-K, отсутствием или неэффективностью таких средств контроля, как CAPTCHA и ограничение частоты запросов, до того как автоматическая активность была остановлена, а также последующие меры по устранению. Эти документы не делают каждый внутренний факт публичным, но они выводят случай за рамки общего предупреждения о повторном использовании паролей.

Они указывают на сбои контроля, которые относились к платформе.

Именно поэтому восстановление прав — правильная призма. Если единственный урок — что потребители должны использовать уникальные пароли, то обязанность компании исчезает слишком рано. Предписание NYDFS показывает, почему это неполно. Раскрытые данные были связаны с доступностью формы 1099-K, внутренним процессом изменений, решениями о маскировании, средствами контроля доступа к учётным записям, риск-ориентированной аутентификацией и восстановлением учётных записей клиентов. Потребитель не мог проверить эти средства контроля до события. Малый продавец не мог знать, стала ли налоговая форма видимой с большим объёмом данных, чем необходимо.

Банк не мог сделать вывод о том, означает ли несанкционированный вход в PayPal более широкий идентификационный риск.

Восстановление прав должно было превратить данные платформы в действия пользователя.

Собственные публичные страницы безопасности PayPal также показывают практическую форму таких действий пользователя. Центр безопасности по адресуисточник: paypal.comнаправляет пользователей к сообщению о мошенничестве, сообщению о подозрительных сообщениях, советам по защите и помощи в восстановлении учётной записи. Страница о мошенничестве по адресуисточник: paypal.comсоветует пользователям сообщать о несанкционированной активности и проверять связанные финансовые счета. Эти страницы полезны, но они не заменяют доказательств, специфичных для инцидента. Общая справочная страница может рассказать человеку, как действовать.

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

Этот случай также относится сюда, потому что форма 1099-K — это не обычное содержимое учётной записи. Руководство IRS по адресуисточник: irs.govобъясняет, почему платёжные приложения и интернет-площадки отправляют эту форму пользователям и правительству. Этот налоговый контекст повышает ставки в случае инцидента со входом. Если несанкционированный доступ достигает налоговой формы, проблема уже не только в том, ушли ли деньги со счёта. Она может включать имена, адреса, даты рождения, налоговые идентификаторы, данные о доходах малого бизнеса и пути мошенничества, которые продолжаются после сброса пароля. Поэтому запись о подотчётности должна связывать средства контроля аутентификации с минимизацией данных и контролем дизайна форм.

Первая обязанность — отделить поведение злоумышленника от контроля платформы

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

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

Соглашение о мерах принудительного характера NYDFS важно, потому что использует ту же практическую рамку. В нём говорится, что соответствующая активность не была просто абстрактной волной атак. PayPal внёс изменения в потоки данных для доступности формы 1099-K; формы содержали незамаскированную непубличную информацию; всплеск попыток доступа был расценён как подбор учётных данных; позднее PayPal добавил CAPTCHA и ограничение частоты запросов, замаскировал раскрытую информацию, принудительно сбросил пароли для затронутых учётных записей и перешёл к требованию MFA для всех входов в клиентские учётные записи в США.

Это решения, связанные с контролем.

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

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

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

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

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

Именно таких доказательств читателям не хватало от PayPal.

Граница источников важна. Справочные страницы компании доказывают, что PayPal советует пользователям делать сейчас. Регуляторные документы доказывают, что обнаружил и урегулировал DFS. Стандартные документы дают словарь средств контроля. Ни один из них по отдельности не доказывает каждую деталь частной судебной экспертизы. Вместе они поддерживают публичную проверку, которая не выходит за рамки. Досье о подотчётности не должно притворяться, что посторонние могут видеть внутренние журналы. Оно должно спрашивать, даёт ли публичный материал затронутым людям практический способ оценить их следующее действие.

Уведомление должно отвечать на решение пользователя, а не на категорию компании

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

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

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

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

Запись DFS помогает, связывая событие с незамаскированными данными формы 1099-K. Страница IRS о форме 1099-K по адресуисточник: irs.govобъясняет, почему организации, осуществляющие расчёты с третьими лицами, отправляют эти формы и почему пользователи используют их с налоговыми записями. Этот контекст должен определять уведомления. Уведомление платёжной платформы должно разделять риск транзакции, идентификационный риск, риск налоговых записей и риск сброса учётной записи. Это не юридические украшения; это решения пользователя.

Уведомление также должно описывать, что компания уже изменила — маскирование, ограничение частоты запросов, CAPTCHA, сброс паролей и изменения MFA, — потому что пользователям нужно знать, снизила ли платформа условие, которое их раскрыло.

Руководство FTC для бизнеса по реагированию на утечки по адресуисточник: FTCздесь полезно, поскольку оно описывает реакцию как локализацию, оценку, уведомление и помощь затронутым людям. Сопутствующее руководство по защите личной информации по адресуисточник: FTCподчёркивает сбор, хранение, защиту и уничтожение. Для PayPal эти концепции указывают на два вопроса. Было ли чувствительное поле необходимым в отображении после входа? Если да, то почему оно не было замаскировано в соответствующем сеансе учётной записи, и какой устойчивый к злоупотреблениям контроль стоял между подобранным паролем и полным полем?

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

Пользователи могут справиться с неопределённостью, когда она названа.

Им хуже, когда неопределённость сглаживается в одно заверение.

Восстановление прав — это поверхность контроля, а не только обслуживание клиентов

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

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

Четвёртый шаг — уверенность: объяснить, какие средства контроля платформы изменились и как компания знает, что автоматическая активность прекратилась.

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

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

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

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

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

Минимизация данных — часть безопасности входа

Инцидент PayPal показывает, почему минимизация данных относится к статье об аутентификации. Средства контроля входа — это лишь один слой. Если успешный вход раскрывает больше чувствительных данных, чем нужно пользователю, каждое событие злоупотребления учётной записью становится серьёзнее. В случае PayPal предписание DFS указывает на незамаскированную информацию из формы 1099-K. Это означает, что вопрос дизайна не только в том, могли ли злоумышленники войти.

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

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

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

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

Глобальная платформа не может делать бремя восстановления зависимым от способности пользователя расшифровывать внутренние потоки данных.

Критические средства контроля CIS по адресуисточник: cisecurity.orgи структура кибербезопасности NIST по адресуисточник: nist.govдают категории контроля для инвентаризации, управления доступом, защиты данных, мониторинга, реагирования и улучшения. В этом случае эти категории превращаются в практические вопросы. Знал ли PayPal, где появляются полные идентификаторы? Были ли чувствительные экраны внесены в реестр как поверхности высокого риска? Требовал ли процесс изменений проверки конфиденциальности и безопасности? Обнаруживал ли мониторинг автоматизированный доступ к новым формам? Проверяло ли исправление, что чувствительные поля замаскированы везде, куда дошло изменение?

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

Доказательства платформы должны быть достаточно конкретными для банков и регуляторов

Инциденты платёжных платформ распространяются вовне. Банкам нужно знать, использовались ли связанные инструменты. Кредитным бюро и службам защиты от кражи личности нужно знать, были ли раскрыты чувствительные идентификаторы. Регуляторам нужно знать, какие юридические обязанности были затронуты. Клиентам нужно знать, оправданы ли сообщения о мошенничестве или краже личности. Страница PayPal о мошенничестве даёт ссылки на государственные пути сообщения, такие какисточник: FTCиисточник: identitytheft.gov. Эти внешние пути полезны только тогда, когда пользователь может описать, что произошло, с достаточной конкретностью, чтобы отчёт был осмысленным.

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

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

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

Подотчётность означает, что учреждение, у которого есть журналы, должно нести большую часть объяснительного груза.

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

Ресурс CISA по управлению идентификацией и доступом по адресуисточник: cisa.govполезен как справочник по контролю, поскольку он связывает аутентификацию, доступ и организационную ответственность. В инциденте платёжной платформы средства контроля идентичности — это не только механика входа. Это системы доказательств. Они должны показывать, какой пользователь, какое устройство, какой сеанс, какая поверхность данных, какое решение и какой путь восстановления. Если эти доказательства доступны только внутри, компания может исправить систему, но оставить затронутых пользователей неспособными доказать, что с ними произошло.

Лучшая профилактика сделала бы возможным лучшее восстановление

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

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

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

Каждая упущенная точка профилактики позже становилась отсутствующим или более трудным фактом восстановления.

Руководство по безопасному проектированию по адресуисточник: cisa.govактуально, поскольку оно просит поставщиков технологий делать безопасные результаты проще для клиентов по умолчанию. Для PayPal вопрос безопасного проектирования в том, должны ли пользователи были соглашаться на более сильную защиту до того, как полная чувствительная налоговая информация могла быть отображена. Предписание NYDFS отмечает, что PayPal позже потребовал MFA для всех входов в клиентские учётные записи в США. Такое исправление — не просто дополнение. Оно меняет профиль риска по умолчанию для людей, которые могут никогда не прочитать страницу безопасности и могут не понимать, как работает подбор учётных данных.

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

Лучшая запись о профилактике поэтому включала бы как технические, так и управленческие доказательства. Технически она показала бы попытки аутентификации, ограничения частоты, паттерны устройств и IP, контроль сеансов, правила отображения полей и изменения маскирования. Управленческие доказательства показали бы, кто одобрил изменение формы 1099-K, какая проверка была пропущена или неправильно классифицирована, кто исправил классификацию, какое обучение изменилось и как будущие выкладки кода проверяются на требуемые одобрения. Предписание DFS называет несколько таких тем исправления.

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

Подотчётность должна следовать пути раскрытого факта

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

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

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

Каждый факт нуждается в собственной линии доказательств.

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

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

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

Качество восстановления — это отсроченный продукт более ранних проектных решений.

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

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

Что должна содержать полная запись о восстановлении

Полная запись о восстановлении для PayPal начиналась бы с хронологии. В ней указывалось бы, когда соответствующее изменение формы 1099-K вступило в силу, когда компания впервые обнаружила публичные или внутренние сигналы злоупотребления, когда был идентифицирован автоматизированный доступ, когда были добавлены такие средства контроля, как CAPTCHA и ограничение частоты запросов, когда чувствительные поля были замаскированы, когда были сброшены пароли, когда изменились требования MFA и когда были уведомлены затронутые пользователи. Каждая дата должна быть привязана к источнику доказательств и затронутой аудитории.

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

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

Если чувствительное поле было раскрыто, потому что оно было необходимо для формы, компания должна объяснить, почему было необходимо полное отображение и что изменилось.

Третья часть — матрица действий пользователя. Потребителям, малым продавцам, банкам, антифрод-командам и регуляторам не нужны одинаковые инструкции. Потребителю могут понадобиться сброс паролей, включение MFA, кредитный мониторинг, отчёт о краже личности и проверка несанкционированных транзакций. Продавцу могут понадобиться проверка налоговых записей, валидация контактов учётной записи, сверка выплат и документация для банка. Регулятору могут понадобиться количество пострадавших, категории данных, сбои контроля и меры по исправлению. Банку может понадобиться краткое описание инцидента и объём затронутых полей.

Запись о восстановлении должна направлять каждую аудиторию, не закапывая её в общие советы по безопасности.

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

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

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

Файл доказательств для читателя

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

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

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

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

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

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

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