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

Для банка одноразовый пароль (OTP) — это не просто уведомление. Это средство контроля наиболее важных с точки зрения безопасности процессов взаимодействия с клиентами: вход в систему, подтверждение транзакции, добавление получателя, активация карты, привязка устройства. Цена, которую не приносит OTP, — это потерянный клиент; цена, которую приносит OTP, но перехватывается, воспроизводится повторно или исчерпывается автоматическим зондированием, — это прямые потери от мошенничества и обсуждение с регулятором. Поэтому банкам необходима более эффективная практика использования OTP, чем другим отправителям A2P-трафика: более совершенная система мониторинга, более агрессивное оповещение о мошеннических схемах и документированный алгоритм действий в случае предсказуемых сбоев. Вот как выглядит эта практика.

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

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

1. 1Показатель доставки от отправителя до получателя — доля запросов OTP, по которым оператор получателя вернул положительный результат DLR в течение срока действия OTP. Это реальное число доставленных запросов, а не процент принятых отправленных запросов.
2. 2Задержка p50, p95, p99 — данные, передаваемые на устройство, по каждому каналу, по каждому оператору связи. Отслеживается как временной ряд, а не как одно число; условием оповещения является ухудшение по отношению к скользящему базовому уровню, а не к абсолютному пороговому значению.
3. 3Показатель повторных попыток — доля запросов OTP, которые привели к повторной отправке по инициативе пользователя или системы в течение срока действия. Рост показателя повторных попыток является самым ранним сигналом ухудшения качества основной доставки; он почти всегда предшествует явному падению показателя доставки.
4. 4Показатель отклонения идентификаторов отправителя — доля заявок, отклоненных на уровне оператора по причине несоответствия идентификаторам отправителя. Ненулевое значение в этом случае указывает на проблему с регистрацией; об этом следует сообщать как о проблеме с нулевой терпимостью.
5. 5Показатель успешного ввода OTP — доля запросов OTP, в которых пользователь успешно ввел код. Это единственный KPI, имеющий коммерческое значение; все остальное влияет на него. 99% показатель доставки в сочетании с 70% показателем успешного ввода говорит о том, что сообщение пришло слишком медленно или пользовательский интерфейс при вводе кода не работает; доставка без успешного ввода не означает успеха.

Признаки мошенничества, на которые стоит обратить внимание.

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

1. Повторные запросы OTP для одного и того же MSISDN.

Злоумышленник, отслеживающий поток одноразовых паролей (OTP) для одной учетной записи — вручную или с помощью скрипта — генерирует характерную сигнатуру: множество запросов OTP для одного номера телефона, часто сгруппированных по времени, иногда с меняющимися IP-адресами или строками User-Agent в исходной сессии. Легитимный аналог (пользователь, который действительно не может найти код) достигает максимума в три-пять попыток за несколько минут; профиль атаки — десятки или сотни. Пороги оповещений должны быть жесткими: более десяти запросов OTP для одного MSISDN за пятнадцать минут почти всегда являются либо атакой, либо нарушением интеграции, и то, и другое заслуживает внимания.

2. Географические и поведенческие аномалии

Запрос одноразового пароля (OTP) от пользователя, находящегося в одной стране, для номера телефона, ранее связанного с другой страной, не обязательно является мошенничеством — это может быть клиент, находящийся в поездке, — но стоит повысить уровень аутентификации, а не просто молча подтвердить запрос. В сочетании с изменениями в отпечатках устройства (новый браузер, новый идентификатор устройства, новая установка приложения) сигнал становится сильнее. Система управления рисками банка уже должна это делать для авторизации транзакций; расширение этой функции на выдачу OTP — это быстрый и эффективный способ.

3. Ограниченное перечисление и подбор учетных данных

Более изощренный злоумышленник перечисляет идентификаторы учетных записей через процесс восстановления пароля, намеренно оставаясь вне зоны действия ограничения на количество запросов OTP для каждой учетной записи, но одновременно проверяя множество учетных записей. Характерной чертой является высокая частота запросов OTP по множеству различных MSISDN из небольшого диапазона источников, часто с низким количеством запросов для каждой учетной записи MSISDN, что не позволяет сработать оповещения по каждой учетной записи. Для обнаружения требуется агрегирование по источникам (IP-адрес, класс устройства, шаблон сессии), а не по каждой учетной записи. Это в точности соответствует схеме атак с использованием SMS-накачки, которые некоторые злоумышленники применяют против инфраструктуры OTP для монетизации скидок от провайдеров за каждое сообщение; защита от этого одновременно защищает как от мошенничества, так и от завышения стоимости услуг провайдера.

Оперативное руководство по предсказуемым режимам отказов

В каждом банке повторяются три типа инцидентов, связанных с одноразовыми платежами. Наличие письменного плана действий для каждого из них — а не плана, разработанного под давлением, — отличает 15-минутное восстановление от 4-часового.

Сценарий 1 — ухудшение качества маршрута оператора назначения

Сигнал: задержка p95 увеличивается у конкретного оператора назначения, в то время как у остальных она остается неизменной, скорость доставки к этому оператору падает. Действие: подтвердить, что ухудшение происходит на стороне маршрута, а не внутри системы (принятие заявок по-прежнему составляет 100%), переключить трафик OTP для этого оператора на вторичный маршрут в механизме маршрутизации, уведомить центр управления сетью провайдера для подтверждения и оценки времени прибытия. Восстановление: как только метрики основного маршрута вернутся к базовому уровню в течение 30 минут, восстановить работу. Полный сценарий должен состоять из десяти строк и отрабатываться ежеквартально.

Второй сценарий — резкий рост отказов по идентификатору отправителя.

Сигнал: процент отклонений идентификаторов отправителей резко возрастает с нуля до ненулевого значения, почти всегда для одного из целевых рынков. Действие: проверьте, истек ли срок действия регистрации идентификатора отправителя или он был отозван у целевого регулятора (наиболее распространенная причина), подтвердите это у местного агрегатора, переключитесь на резервный зарегистрированный идентификатор отправителя для затронутого рынка, если таковой имеется, и эскалируйте регистрацию. Время восстановления определяется регулятором, а не банком; задача сценария — ограничить последствия во время ожидания.

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

Сигнал: стоимость одного успешного OTP резко возрастает; резко увеличивается объем отправленных запросов на определенные диапазоны номеров (часто смежные с префиксами платных номеров или номеров определенных стран); процент завершения таких запросов близок к нулю. Действие: включите список разрешенных номеров для префиксов назначения, если он еще не включен (это наиболее эффективный способ контроля), ограничьте отправку OTP с затронутых каналов связи, свяжитесь с отделом по борьбе с мошенничеством поставщика услуг обмена сообщениями. Восстановление: отключите список разрешенных номеров после прекращения атаки — для большинства банков небезопасно оставлять его постоянно отключенным. См. HLR Lookup pre-flight в качестве структурного средства защиты от этого класса атак.

Архитектурные решения, которые делают возможным создание игровых схем.

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

• Многоканальная система одноразовых паролей с самого начала — как минимум SMS и голосовая аутентификация; в идеале — SMS, шаблон аутентификации WhatsApp и голосовая аутентификация с документированным автоматическим переключением на резервный канал. Переключение на резервный канал — это механизм управления, а не резервный вариант; его можно будет активировать для каждого маршрута и категории без изменений в коде.
• Телеметрия доставки и задержки по каждому каналу и оператору — без нее приведенные выше панели мониторинга остаются лишь желательными. Данные должны поступать от поставщика услуг обмена сообщениями в виде структурированных потоков DLR, а не в виде ежемесячных PDF-отчетов.
• Документированный реестр идентификаторов отправителей с датами обновления — этот реестр должен принадлежать отделу по соблюдению нормативных требований банка, а не поставщику услуг обмена сообщениями; упущения, вызванные недосмотром поставщика услуг в отношении обновления, по-прежнему остаются проблемой банка, когда прекращается поступление сообщений.

Разговор с провайдером — какие данные должны передаваться обратно?

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

• Веб-хуки DLR в реальном времени, подлинность которых банк может проверить (например, подпись HMAC-SHA256 с общим секретом, если провайдер подписывает обратные вызовы, или список разрешенных IP-адресов), чтобы банк мог сопоставлять отправленные данные с фактической доставкой в своей SIEM-системе.
• Ежедневные отчеты о доставке и задержках с разбивкой по оператору назначения, идентификатору отправителя и маршруту, пригодные для интеграции в систему мониторинга банка.
• Ежемесячные сводки инцидентов с указанием хронологии, первопричин и мер по устранению любых инцидентов на стороне поставщика услуг, повлиявших на трафик банка.
• Прямые контакты с операционным центром и группой по борьбе с мошенничеством поставщика услуг в рамках соглашения об уровне обслуживания (SLA) с указанием времени ответа.

Готовность к действию регулирующих органов — часто упускаемый из виду аспект.

Центральные банки и регуляторы финансовых услуг все чаще задают во время проверок конкретные вопросы об инфраструктуре доставки одноразовых паролей (OTP): каково соглашение об уровне обслуживания (SLA), как работает механизм резервирования, как ведется аудит, как выявляются схемы мошенничества и как на них реагируют. Банки, которые могут ответить за пять минут, используя стандартное операционное досье, проходят проверку без проблем; банки, которым приходится собирать ответ в середине проверки, — нет. Приведенные выше ключевые показатели эффективности (KPI) и руководства являются исходными данными для этого досье; рассматривайте их как документы, подтверждающие соответствие требованиям, а также как операционные документы.

Распространенная ошибка при выходе на пенсию.

Многие банки внедряют OTP как функцию сервиса аутентификации, а не как самостоятельную систему. В результате: интеграция с системой обмена сообщениями находится в ведении того, кто изначально разработал процесс аутентификации, часто это человек, который с тех пор сменил команду; никто не обращает внимания на телеметрию доставки данных по каждому оператору; первым признаком ухудшения является всплеск обращений в службу поддержки клиентов, который команда поддержки не может связать с проблемой в системе обмена сообщениями. Решение проблемы носит структурный характер — назначается ответственный за инфраструктуру OTP с небольшой постоянной командой (или четко обозначенной партнерской командой), проводится ежеквартальный обзор панели KPI и ежегодное комплексное тестирование описанных выше сценариев на основе реалистичного сценария инцидента. Все поставщики услуг обмена сообщениями для институциональных банков проводят ежеквартальные совместные обзоры со своими клиентами в рамках взаимодействия; если ваш поставщик этого не делает, запросите это.

Как выглядит хороший результат в цифрах

Хорошо организованная банковская инфраструктура OTP, осуществляющая отправку сообщений на регулируемый рынок стран Персидского залива по прямым каналам операторов, с резервной цепочкой и описанными выше средствами контроля мошенничества, должна обеспечивать: более 99% сквозного подтверждения (не просто доставку — фактическую проверку клиентом), задержку p95 менее пяти секунд по основному каналу, нулевой процент отклонений идентификатора отправителя, процент повторных попыток менее 3% (при превышении этого показателя ухудшается как пользовательский опыт, так и стоимость), а также блокировку запросов OTP, связанных с мошенничеством, менее 1% легитимного трафика (ложные срабатывания имеют значение — слишком агрессивная блокировка сама по себе является проблемой для пользовательского опыта). Банки, показатели которых значительно ниже этих значений, имеют в эксплуатации одну или несколько из семи причин сбоев, описанных в руководстве по устранению неполадок с доставкой OTP; перед настройкой необходимо провести диагностику.

Рекомендуемая литература

• Почему сообщения OTP не доставляются и как исправить проблемы с доставкой
• Как экспресс-верификация звонков влияет на доходы операторов A2P
• Стратегия омниканального обмена сообщениями для электронной коммерции и логистики
• Глоссарий — что такое OTP, что такое SMS-накачка, что такое DLR
• Страницы продуктов — Сервис OTP и Голосовой OTP MyOTP
• Покрытие — Маршрутизация, соответствующая требованиям OTP и TDRA в ОАЭ