[Из песочницы] Как мы антифрод систему в четыре руки и три головы писали
Статья про создание inhouse-решения для обнаружения и предотвращения мошеннических операций проводимых в интернет-банкинге одного маленького, но очень гордого банка в Татарстане. Из статьи узнаете о том зачем и кому нужен антифрод, почему внутренняя разработка оказалась дешевле покупки готового решения и к чему приводят пара строчек кода перед новым годом.
Пара слов о себе — специалист по Информационной безопасности в ИТ-компании, который случайно (а может и не очень) оказался продакт-оунером (Product Owner) в команде по разработке Антифрод-решения. Сама ИТ-компания занимается разработкой программного обеспечения Интернет-Банкинга.
С чего вообще все началось
Для самого банка, началось всё с того что Центральный банк Российской Федерации выложил проект изменений и дополнений в Положение № 382-П, который говорил о том, что банк должен предотвращать осуществление переводов денежных средств без согласия клиента. К тому же, согласно указанию Банка России № 2831-У, банк обязан отчитываться перед Центробанком обо всех инцидентах, в том числе о действиях мошенников.
Для меня же, история началась с просьбы помочь с формированием функциональных требований и проработкой интеграции с имеющимся сервисом дистанционного банковского обслуживания (далее — ДБО). И понеслось…
Вводные данные
Перед разработкой необходимо исследовать тему, изучить уже готовые наработки грабли, просмотреть рынок.
В ходе исследования, выяснилось:
- самые частые способы украсть деньги из ДБО — социальная инженерия и фишинг
- с помощью социальной инженерии либо взламывают ДБО, либо заставляют клиента добровольно перевести деньги
- суммы украденные мошенниками за год не такие большие, банк тратит на расследование и возмещение около 10% от этой суммы
- стоимость готового антифрод решения превышает сумму участвовавшей во фроде в 5–10 раз (про стоимость интеграции речи еще не шло…)
- надо отчитываться перед ФинЦЕРТом, обязательно
- можно выделить пару очень частых и важных кейсов
При анализе темы антифрода, мне очень помогли статьи codezombie. Который 4 года назад написал про антифрод используемый в e-commerce, про свой опыт. В моем случае, специфика отличалась, но информация была очень ценной.
Отталкиваясь от этих условий, было принято решение отдать проект команде разработчиков занимающейся интеграциями и решением проблем других команд, так как в этой команде находились самые опытные и крутые разработчики. К сожалению, в команде из 3 разработчиков с течением времени осталось лишь двое. Я занимался бэклогом, формированием требований, документацией и организацией встреч (работаем по скраму, а как иначе). Так и получилось, что в команде 4 руки писали код, а 3 головы решали задачи.
Кейсы, с которыми боролись
Не подумайте что в банке до этого не боролись со злом с мошенниками. Боролись доступными средствами. Однако, сложилась тенденция что количество инцидентов связанных со взломом ДБО стало расти. Популярной схемой 2018 года стал развод на просторах Авито — продавцы-мошенники с помощью методов социальной инженерии узнавали номер карты, а в диалоге узнавали смс для входа в ДБО. Таким образом, получали полный доступ к интернет-банкингу конкретного клиента. В 2019 году мошенники начали обзванивать клиентов от имени служб безопасности банка, угрожая потерей всех денег узнавали реквизиты для входа, или убеждали перевести все денежные средства на «безопасный счет».
Основной целью команды разработки стало создание механизма определения новых устройств клиентов и остановки подозрительных финансовых транзакций. Почему именно новых устройств? Аналитика показала что чаще всего получают доступ к ДБО через смартфон, чтобы получать коды подтверждения через PUSH-уведомления, а не СМС-сообщения.
Кроме того, ФинЦЕРТ начал присылать списки реквизитов участвовавших в мошеннических операциях, то есть, их надо было обязательно блокировать.
Разработка и интеграция в Антифроде
У нас было 2 крутых .NET-программиста, микросервисная архитектура ДБО, REST API, дюжина черных списков разных форм и целое множество интеграций всех сортов и расцветок, а также не было тестировщиков и devops-инженера. Не то чтобы это был необходимый запас для защиты от всех мошенников. Но если все же надо сделать, то уже не остановиться. Единственное что вызывало у меня опасение — это ложные срабатывания. Нет ничего более беспомощного, безответственного и испорченного, чем оператор антифрода у которого прилетело 20 тикетов за 5 минут. Я знал, что рано или поздно мы столкнемся и с этим.
Вообще, ничего страшного в интеграции не было. SLA установил лимит в 3 секунды на ответ по запросам. На данный момент, среднее время ответа — 0,3 секунды. Микросервисная архитектура позволила легко интегрироваться с имеющимся решением, добавив три строки для отправки запроса в микросервис антифрода. Проверка происходит до момента подтверждения СМС или PUSH-уведомлением.
Небольшой набросок архитектуры решения: 
На первом этапе разработки, была поставлена цель — проверять два важных условия. Во-первых, устройство с которого производится попытка транзакции новое для клиента или оно доверенное. Во-вторых, не находится ли реквизит в черных списках. Этих двух условий хватает чтобы блокировать 70% возникающих инцидентов, для остальных же требуется больше информации, например был ли вход по логин\паролю, или по номеру карты, из какой страны произошел вход в ДБО и т.д.
Для применения проверки нужно не так много данных — уникальный идентификатор клиента, идентификатор его устройства (создается на самих клиентах — мобильных приложениях и JS-библиотеками на сайте), сумма перевода, реквизиты перевода. По этим данным принимается решение о разрешении или блокировки операции. Как только вся система исправно заработала в промышленной эксплуатации, команда перешла к следующему этапу. Появились белые списки и автоматическая загрузка списков из ФинЦЕРТ. На данный момент, отлаживается отправка отчетов по инцидентам в сам ФинЦЕРТ по API (это отдельная долгая история).
На данный момент, в системе Антифрод реализована проверка следующих платежей: P2P-платежи по номеру карты, пополнение номера телефона, перевод по реквизитам, пополнение электронных кошельков. Мошенники часто переводят по 2000–3000 рублей на номера телефонов или кошельки. В случае с картами, обычно суммы близки к сумме всех имеющихся денежных средств клиента. Кроме проверок, была создана страница для операторов Антифрода, систему полностью автономной сделать не получается — человек нужен для мониторинга событий, расследования инцидентов, блокирования/разблокирования, создания отчетов по системе. Сложно делать сайт, когда в команде два backend-разработчика. Однако, никогда не поздно научиться (круто когда в команде T-shaped специалисты!).
В самом начале, при планировании и анализе, было очень много мыслей о внедрении машинного обучения, динамических правил, антивирусах внутри клиента ДБО. Однако, судя по опыту вендоров и других банков, больше половины кейсов можно закрыть применением статических правил. Все остальные методы требуют больших ресурсов и не так эффективны. Именно поэтому, команды из двух разработчиков и одного аналитика (коим себя и считаю) хватает для реализации минимальных мер защиты и требований регуляторов.
Боль
Основное правило действующее при разработке Антифрода — не навреди. Любые изменения и новые методы должны быть опробованы сначала на тесте, затем на бою в режиме мониторинга, чтобы убедиться в исправности и отсутствии проблем. В худшем случае, ошибки могут привести к финансовым потерям и потере лояльности клиентов. В нашем случае, ошибка привела к страданиям операторов, расследующих и управляющих системой Антифрод.
Дело было вечером, под Новый Год. В системе была реализована проверка не только мобильных устройств, но и браузеров клиентов. С помощью EverCookie. Разработчики фичу включили, но её не испытывали, так как на фронтах библиотеку не внедряли. Только вот в последний рабочий день 2019 года, фронтенд программист решил вылить ветку в прод (ну не оставлять же на следующий год!). Из-за этого, во время Новогодних выходных на операторов Антифрода навалилось много работы в виде ложных срабатываний системы. Нельзя сказать что это было критично, однако, операторов немного жалко… ведь работы стало раз в 5 больше чем это было до выливки изменений.
Итоги
Меньше чем за год, очень маленькая команда реализовала систему Антифрода для Интернет-Банкинга. К сожалению, работы еще очень много. Пообщавшись на форуме Antifraud Russia с представителями банков и вендоров, стало ясно что мошенники с каждым годом придумывают новые способы, расслабляться в этой сфере никак нельзя.
Если будет интересно, напишу больше о программных решениях, аналитике рынка и о том как внедрить Scrum в команде из 3 человек.
