На самом деле, правило фиговое. Но понятное дело, почему оно работает. В среде безопасников считается, что антифрод должен быть такой суперсекретной штуковиной за семью печатями с парой голодных Церберов поблизости. Чтобы никто-никто не мог заглянуть в щель и узнать, как этот антифрод работает и вообще, чего там внутри. Безопасникам это добавляет важности, а самому механизму антифрода — иллюзорную защиту.
Принцип security through obscurity не работает. Если пойти погуглить насчет новостей в разрезе «Клиента банка Х взломали и увели Y рублей», то такие новости будут всегда. Почти каждый день (почти — потому что не всегда об этом пишут).
Реализации всех известных протоколов шифрования открыты и доступны для изучения. Все криптографические и математические алгоритмы тоже описаны, причем весьма подробно. То есть садись, запасайся кофе или энергетиками, изучай все это добро да ломай себе потихоньку.
Поэтому система, которая считается защищенной только потому, что люди не знают, как она работает — вообще ни разу не защищенная. А вот чем такая система открытее, тем быстрее въедливое сообщество укажет своим критически настроенным перстом на все косяки в реализации. Что позволит эти косяки устранить.
Я работаю именно в парадигме открытости протоколов и систем, и в этом посте я хочу рассказать про устройство стандартного антифрода, о работе нашего в RBK.money, почему будущее за OpenSource, а также о том, как всё это может работать в идеальном мире.
Который мы с вами и можем приблизить.
Антифрод под капотом
Начнем с самых простых примеров. Антифрод — это совокупность двух машин. Первая работает по каким-то правилам, которые вы знаете и которые вам понятны. Вторая — черный ящик, в котором творится магия, постичь которую не помогут даже канистра энергетика и томик Ницше.
То есть в первой машине у нас лежит набор правил, написанный человеком. Правила выглядят довольно просто и всего-навсего отражают определенный набор действий, который должен триггерить систему на распознание фрода. Например, если с такой-то карты внезапно понеслось по 10 платежей в минуту, это неслабый такой повод насторожиться. Или если транзакция по карте прошла в Питере, а 5 минут назад хозяин по ней снимал деньги в Москве — тут тоже что-то странное.
Я повторюсь, я сейчас сильно образно, потому что такое поведение может быть и в нормальной ситуации. Например, Амазон любит снимать деньги не за весь ваш заказ из 15 позиций, а за каждую позицию по отдельности. Причем в разное время, это нормально. А в случае с географической разницей — хозяин карты может быть в Москве, а в Питере что-то на эту же карту в Apple Pay покупает его мама. Да, на картах пишут, что их не стоит передавать третьим лицам и вот это всё, но жизнь обычно немного сложнее.
Про вторую коробку. Там лежит большой кусок machine learning, и тут конкретно показать на пальцах в простой структуре, как там чего с чем соотносится для выводов, уже не так просто.
И вот из этого базиса можно вывести критерии хорошего антифрода.
Три кита
Во-первых, это интерфейс написания правил. Удобный, красивый и понятный. Об этом будет чуть ниже.
Во-вторых, специальный язык написания этих правил.
В-третьих, быстрая обработка этих написанных правил.
Почему быстро — потому что скорость тут реально важна. Антифрод как сущность ставится в разрыв платежной системы. И тут есть два подхода подобной реализации.
1) Bypass
Здесь в приоритете именно скорость проведения платежей. Бизнес обычно в такой ситуации принимает решения, что приоритет по скорости терять не стоит, поэтому если вдруг антифрод будет что-то долго обдумывать, анализировать и в целом немного тормозить процесс — пофиг, пляшем, игнорируем показания антифрода и просто проводим платеж.
2) Минимизация рисков
В этой ситуации бизнес понимает, что антифрод, в общем-то, не просто так поставили в систему, и прислушивается к его показаниям. Если есть подозрение на фрод, то бизнес тормозится, разбираются в ситуации, и только потом платеж проводится. Или не проводится.
Поэтому антифрод должен быть быстрым, максимально быстрым, и при этом адекватно конфигурироваться.
Внутри самого антифрода, на самом деле, довольно несложные колоночные вещи, там уйма задач на агрегацию данных. Вот смотрите, что собирается система:
- ip
- fingerprint
- БИН банка
- ID мерчанта
- токен карты
И есть задача вида схлопнуть в окне движущееся сейчас количество платежей с конкретным значением. Например, посмотреть прямо сейчас, что проводится с определенного фингерпринта. Или уточнить проходящие платежи по конкретной карте. Это очень помогает работе.
Да, кстати, важно понимать, что антифрод — это не вещь в себе. Он не может быть плохим или хорошим, это инструмент, требующий настройки. И если антифрод работает хреново, это не потому, что антифрод хреновый — это его хреново настроили, вписали не те правила или не учли еще кучу важных штук.
А настраивать его правильно важно для бизнеса. Не только потому, что из банка, где антифрод хреновый, все клиенты разбегутся, а потому, что отрасль тут сильно зарегулирована. Если в банк приходит слишком много фродового чарджбека, это повод для штрафов и дополнительных проверок. Ну а если совсем все грустно, то отключат нафиг от платежной системы.
И это правильно. Если ты оперируешь чужими деньгами, люди тебе их доверяют, а ты не в состоянии их защитить — на кой ты вообще на рынке? Открой шиномонтаж, например.
Поэтому у тебя или хорошо настроенный антифрод, или никакого вообще, ибо тебя выкинули с рынка и он тебе больше не нужен.
Своя рубаха
Когда мы писали свой антифрод, мы смотрели на все это, проверяли работоспособность, и поставили в итоге ClickHouse.
Работает это так. У нас есть платёжная система, которой активно пользуются. Соответственно, генерится большое количество событий. Все эти события мы единым потоком сливаем в ClickHouse, где они успешно агрегируются и обрабатываются. И обрабатываются быстро.
Некоторое время назад у нас был вендорский антифрод. Вполне себе решение, работало по подписке, особых неудобств не доставляло. Но когда мы вывели для себя критерии правильного антифрода, мы стали писать свой. Писали мы его суммарно месяца два, внешняя апишечка описана swagger-ом. Когда закончили, стали тестить, сначала пускали почти весь трафик на старый, а небольшую часть — на новый. Ну а вдруг там навернется чего.
Не навернулось. Мы его активно отлаживали, использовали на старте как такую добавочную рекомендалочку. А на днях мы полностью перетащили все на него, он ощутимо быстрее старого, шустро отрабатывает все правила, в общем — полет нормальный. Но старый пока лежит как запаска.
Антифрод — это отличная почва для использования возможностей машинного обучения. Ведь на входе есть база (сами платежи), есть определенный датасет, есть модель, которая легко описывается уже известными имеющимися фродами. То есть можно для модели просто взять и на старом потоке платежей отметить — вот, зацени, тут был фрод, ату его, ату. В общем, для полноценной тренировки нейросети тут есть все, бери и пользуйся.
Уютного интерфейса мы пока не сделали, так как пока мы на этапе отлаживания протокола и правил (их у нас штук 200+, новые пишем ежедневно). Система управляется бодрым curl напрямую из консоли. И тут уже главная задача антифродера (да, есть такой специально обученный человек, который именно этим занимается) — сидеть, внимательно смотреть на трафик, получать чарджбеки из-за фрода, корректировать правила. Как видите, роботам пока не удалось полностью спихнуть с работы кожаных мешков.
В общем, новый сейчас хорош. Но пока не прямо отличный-отличный. Хотим впилить туда dry run — это когда ты написал правило, а потом прогнал через него какой-то конкретный платеж с пометкой «А что было бы с платежом, если бы к нему применилось это правило». Это вот ощутимо прокачает его возможности.
А ещё интерфейсы моделирования хочется строить. Ну знаете, как в фильмах, когда бравые ФБР-овцы отслеживают беглеца по кредитке — ага, смотри, вот тут он заправился на кредитку, вон там кофе купил, а в том городе наличку снял. И все это с привязкой к карте, прочим данным, с красивой визуализацией. Дело времени.
Идеальная система
Когда мы допишем наш антифрод, он станет отличным. А вот идеал, как обычно, достижим не так легко.
Идеал, как по мне, построен на абсолютном OpenSource. То есть опенсорсный антифрод на опенсорсном языке и удобный обмен правилами.
Давайте на примере про подобную идеальную систему защиты от DDoS.
Представим, что всех текущих операторов мамкины дудосеры достали так сильно, что они объединились и стали использовать единую базу засранцев. Если на ресурсе какого-то маленького оператора начинается DDoS, он оперативненько смотрит, какому оленю не спится, добавляет айпишники негодяя в блеклист. Обновление блеклиста расходится по единой системе, и все, что связано с этой атакой, блокируется на уровне клиентских подключений.
Вопрос доверия и надежности такой системы решается блокчейном.
С банками можно работать по такой же схеме. Есть общий список антифрод-шаблонов, который расходится по всем банкам. Зафродили, например, зеленый банк, спец среагировали и добавили новый набор правил в список, список обновился, и все, конкретная атака по такой механике больше не работает. Ни в зеленом банке, ни в других ярких цветах.
Система распределенная, у нас же блокчейн, взломать ее нельзя. ОК, если представить, что взломали сам антифрод у одного банка — это все еще проблема банка. Потому что общий у нас только список правил. А сами движки антифрода в каждом банке свои.
Как на самом деле сейчас. Банки — очень консервативные структуры. Очень. Сейчас у них есть небольшая рассылка, приходит письмо на определенных спецов, мол, зацените, а вот тут карта дропа, вот параметры. Но это рассылка. Про оперативность и вовлеченность можно вообще забыть сразу. Но лучше, чем вообще ничего, да.
Так что такую идеальную историю банки вряд ли осилят. Финтех вот вполне себе может потянуть, именно платежные системы и стартапы.
Machine learning вкупе с OpenSource — это будущее антифрода. кто хорошо научится с этим работать, тот сможет взять неплохой куш — индустрия огромна, там миллиарды. Но идеально решения пока нет.
А раз его нет — то есть хорошие возможности выйти на рынок.
Автор: chainick
