На самом деле, правило фиговое. Но понятное дело, почему оно работает. В среде безопасников считается, что антифрод должен быть такой суперсекретной штуковиной за семью печатями с парой голодных Церберов поблизости. Чтобы никто-никто не мог заглянуть в щель и узнать, как этот антифрод работает и вообще, чего там внутри. Безопасникам это добавляет важности, а самому механизму антифрода — иллюзорную защиту.
Принцип 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 — это будущее антифрода. кто хорошо научится с этим работать, тот сможет взять неплохой куш — индустрия огромна, там миллиарды. Но идеально решения пока нет.
А раз его нет — то есть хорошие возможности выйти на рынок.
Что предлагает RBKmoney
А предлагаем мы вам готовый антифрод. Он уже в опенсорсе и абсолютно свободен. Без всяких подводных камней, я прямо сейчас готов отдать все исходники нашего антифрода любому желающему и помочь с его интеграцией в любую платежную систему.
Общее опенсорсное решение позволяет совместно обмениваться экспертизой, обмениваться правилами защиты.
Не говоря уже о комьюнити, которое совместно может допиливать движок, делать какие-то новые вещи, про которые мы или не подумали или не успели сделать.
Это переводит уровень защиты в совершенно новую плоскость. Множество участников платежной индустрии сейчас разрабатывает свои собственные решения, еще больше — покупают какие-то готовые из тех что есть на рынке.
Не покупайте. Наше решение выиграет любой тендер как минимум по стоимости — с опенсорсным решением трудно конкурировать.
Давайте разрабатывать вместе. Репозитории открыты, исходники есть у вас уже сейчас. Комьюнити всегда лучше, чем что-то делать в одиночку.
Представление RBKmoney Fraudbusters как отдельного продукта, с мануалами по сборке и интеграции будет темой следующей статьи и это будет скоро.
Комментарии (32)
epishman
28.11.2019 20:44Я бы поостерегся пропагандировать энергетики (да и кофе в общем тоже), обычно их фанаты в старости передвигаются на костылях, как человек из медицинской семьи говорю. //off
speshuric
28.11.2019 23:57+1Я не противник, а сторонник open source в целом и в системах, обеспечивающих безопасность в частности (и антифрод в том числе). И совсем не сторонник STO.
Но надо быть объективными: ломать чёрный ящик гораздо сложнее, чем белый при прочих равных. Почему же в криптографии по-другому? В криптографических системах а) если детали реализации не ясны, то непонятно, можно ли доверять системе, б) открытость систем позволяет привлечь к проверке на несколько порядков больше ресурсов, в) позволяет алгоритму/протоколу жить дольше конкретной реализации.
То есть польза для криптографии от открытости просто перевешивает пользу от закрытости. А для антифрода это утверждение лично мне неочевидно. И статья не убедила меня.
Ещё один момент, который нехило подкрепляет предыдущий, это ваша "идеальная система защиты от DDoS". Фишка в том, что описав эту систему вы её сразу разрушили:
- В вашем предложении антиDDoS слишком много от практик Spamhaus. А к этим ребятам вопросов очень много. Collateral damage там всегда на грани допустимого.
- Ваша система сама становится почти идеальным оружием для DoS-атак. Сделать так, чтобы ваша подсеть попала в реестр запрещённых сильно проще, чем DDoSить.
- Вопрос доверия и надежности такой системы решается блокчейном. Если коротко, то нет, не решается. Я не начинаю доверять реестру просто потому, что он на блокчейне.
По мне так, ваша антиDDoS система в том виде, как вы её описали — наивная утопия. Безусловно, если её сильно доработать, то она станет реализуемой, но от вашего примера там останется примерно ничего. Будет ли доработанная открытая антиDDoS лучше существующих решений? Не знаю, но выигрыша от открытости я пока точно не вижу.
chainick Автор
29.11.2019 00:08+1Крутейший комментарий, без сарказма. Я прямо ждал таких, как понимаете, мне очень близка эта тема.
Насчет троянского коня, которым можно завалить всю защиту — правда. Это может быть даже не специально сделано. Посмотрите на текущие реализации BGP например. Любой олень может случайно проанонсить 4 нуля в свою AS и зароутить себе полинтернета. Нужно фильтровать на бордере, т.е. нужно, чтобы участники системы не принимали бездумно все правила.
Но что если посмотреть на систему защиты с той стороны, что предлагаю я?
Участники берут наш антифрод. Он, кстати, в опенсорсе и абсолютно свободен. Без всяких подводных камней, я прямо сейчас готов отдать все исходники нашего антифрода любому желающему и помочь с его интеграцией в любую платежную систему.
Общее опенсорсное решение позволяет совместно обмениваться экспертизой, обмениваться правилами защиты (блокчейн, не блокчейн, тут пофиг вообще, хоть по почте файлы рассылайте).
Не говоря уже о комьюнити, которое совместно может допиливать движок, делать какие-то новые вещи, про которые мы или не подумали или не успели сделать.
Это переводит уровень защиты в совершенно новую плоскость, понимаете что я пытаюсь сделать и в чем моя мечта?
speshuric
29.11.2019 00:18Не, ну если тезисы переформулировать так, то я с ними уже почти согласен. Из статьи это не было видно. Единственное, что в части обмена правил не "блокчейн, не блокчейн, тут пофиг вообще, хоть по почте файлы рассылайте", а кажется, что правильнее и проще через какой-то гитлабо-/гитхабо-подобный сервис это лучше организовать: тут тебе и история с ветками, и процесс ревью с включением а апстрим, и дискуссии, и права пользователей.
chainick Автор
29.11.2019 00:21+1Подредактирую статью насчет этого, спасибо за обратную связь.
Почему я до сих пор не запилил репозиторий с правилами на гитхабе — пресловутый STO, как бы это ни странно звучало.
Я готов дать движок, софт очень неплохого антифрода и развивать его с комьюнили. Но отдать правила вообще всему миру, вот это вопрос.
Стоит ли так делать, или идти дальше по моей задумке, когда мы даем продукт в виде опенсорсного решения, а совместный обмен именно правилами защиты делать в более закрытом комьюнити?
speshuric
29.11.2019 00:26+1Почему я до сих пор не запилили репозиторий с правилами на гитхабе — пресловутый STO, как бы это ни странно звучало.
Я нигде не писал и не подразумевал публикацию прямо на гитхабе. Я имел в виду, что "гитлабо-/гитхабо-подобный сервис" это либо локальный (на своём сервере) отдельный гитлаб с доступом для участников, либо какое-то подобное решение.chainick Автор
29.11.2019 00:39+1Пост подредактировал, надеюсь теперь он больше отражает то, что хотелось донести до аудитории.
Насчет интерфейса обмена правилами — по самому простому пути. ГХ/ГЛ с пулл реквестами и дальнейшим пуллом правил в локальные инсталляции, как-то так.
Спасибо, что не прошли мимо, ваши комментарии помогли лучше структурировать мысль)
Andrey_Green
29.11.2019 01:55Кто завтра на CyberDay в Сколково будет ?? Может вручную переговорим ?)
chainick Автор
29.11.2019 01:58Что ж вы раньше не сказали) Я на конфы только докладчиком хожу, но на эту не приглашали.
0xd34df00d
30.11.2019 04:31Продолжая аналогию с криптографией — алгоритмы-то публичные, а вот ключи оберегают как зеницу ока.
Andrey_Green
29.11.2019 01:30«А к этим ребятам вопросов очень много. Collateral damage там всегда на грани допустимого.
Ваша система сама становится почти идеальным оружием для DoS-атак. Сделать так, чтобы ваша подсеть попала в реестр запрещённых сильно проще, чем DDoSить.»
Так и есть. Это когда щит превращают в карающий меч. Причем цель ddos атаки ДОСТИГАЕтся, а вот перезагрузка серверов и т.д. к освобождению атакованного хоста неприменима. Придется долго и нудно объясняться с админами всей системы для разблокировки. В итоге ущерб от такой отбитой атаки будет превосходить ущерб от прямой ddos на порядокchainick Автор
29.11.2019 01:37Да, это уязвимости открытой системы, к которыми нужно придумать противодействие. Но не так все плохо, я не призываю бездумно принимать правила, которые говорят "заблокируем все кредитные карты".
Во-первых пресловутый dry-run, который позволит оценить результат применения правил без деплоя их на прод.
Во-вторых, это открытая платформа, но не настолько открытая, чтобы каждый левый дядя с улицы мог внести в нее изменения.
Более того, уже сейчас есть рассылки типа fin-cert, в которых регулярно присылают маскированные паны дропов и прочий скам. Тут предложение централизовать это в более автоматизированном и централизованном виде, плюс универсальный софт, который позволит сделать это с минимальными усилиями.
algotrader2013
29.11.2019 00:38Считали ли эффективность системы с правилами и ml против системы с чистым ml? Я к тому, что кожаные мешки все ещё придумывают правила потому, что так исторически сложилось/руководители не доверяют машине/придумывальщики хорошие ребята, и не хотят из выгонять, или реально машина пока недотягивает, и roc/auc гибридной белково-кремниевой системы реально выше?
chainick Автор
29.11.2019 00:45Самая большая проблема — это платежная конверсия vs защита от фродов. Идеальный антифрод, который дает вам 100% гарантию — это тот, который деклайнит 100% платежей, но бизнес такого не оценит.
Из этого вытекает проблема ML. Почему этот черный ящик отклонил платеж или зароутил его в терминал, покрывающий высокий риск (а там 3DS, убитая конверсия, вот это все)?
С правилами гораздо проще и понятнее, сразу видно, почему.
Ну и по моему опыту, кожаные мешки пока справляются лучше. Комбинаторный взрыв из-за большого количества параметров, которые надо неявно связать между собой, чтобы получить адекватную оценку риска мешает построить нормальную модель нейросети.
yar3333
30.11.2019 01:08+1Разрабатывал две разные системы антифрода для двух разных компаний. Когда дело доходило до ML — каждый раз становилось понятно, что проблема здесь очень не простая. В том смысле, что 1) данных о транзакции у нас не так уж и много, 2) ошибки в сторону отклонения добропорядочных транзакций стоят дорого и 3) достать достаточно достоверные данные в достаточном количестве для обучения нейросети (если брать нейросеть) почти нереально.
chainick Автор
30.11.2019 01:11Вот вот, у меня полностью такой же опыт. Вообще, когда я слышу "машинное обучение" применительно к антифроду, я сразу слегка напрягаюсь — это значит, что скорее всего ушлые маркетологи мне пытаются продать черный ящик результаты работы которого гарантировать никто не собирается, не говоря уже о том, чтобы подписаться за показатели платежной конверсии.
algotrader2013
30.11.2019 15:43Мне повезло больше с ML в антифроде (даже был удивлен, как можно быстро первый результат получить), правда, тема не связанная с чаржбеками, и да, цель была именно решить проблему, а не продать кому-то что-то за счет хайпа, но, как-то, нейросети даже мы не то, чтобы тестировали, а даже и мысли не было использовать.
Johnny_Boy
29.11.2019 12:38Интересно было почитать. Спасибо!
Жду продолжения статьи.
Вы готовы поделиться своей разработкой антифрода совершенно бесплатно?chainick Автор
29.11.2019 12:41Вы готовы поделиться своей разработкой антифрода совершенно бесплатно?
Да.
F_Buster
29.11.2019 14:02Пока тема не раскрыта, но сама концепция бесплатного решения — это хорошо!
Для многих игроков на рынке эквайринга ценники вендорских решений неподъемны, и тут хорошо, если банк эквайер технологичный и прикроет, да так чтоб конверсию не зарубить.chainick Автор
29.11.2019 15:02Ага. Только не бесплатного, а опенсорсного. Все-таки инфраструктуру и вычислительные мощности мы не предоставляем.
squir
29.11.2019 17:00Тут, по-моему, стоит разделить ПО и сами правила. ПО скорее не афишируют, а не скрывают, так как много способов узнать производителя и версии, да и в профильных подразделениях конкурентов, партнеров и контролирующих организаций как правило все знают. А вот правила — это совсем другое дело. Они могут быть как коммерческой тайной, так и способом помочь клиенту. Во многих случаях предотвратить фрод практически невозможно (например, когда клиент введенный в заблуждение сам делает все действия), а вот помочь вернуть ему деньги с помощью правил реально.
Bahuser
29.11.2019 21:43"С банками можно работать по такой же схеме. Есть общий список антифрод-шаблонов, который расходится по всем банкам."
Насколько я знаю, сейчас ведь что-то в этом роде и есть. ФинЦЕРТ формирует, так называемый, Фид-Антифрод. В нем, правда, не шаблоны, а черный список карт/документов/счетов и т.д. Но все это не в виде рассылки, а можно получать по API.
chainick Автор
29.11.2019 21:44Да, я про него писал выше. Там даже не суть в том что по апи, а в том что данные устаревают еще до попадания в этот список. Дроп снял с карты и второй раз ее использовать не будет, блокировать бессмысленно в 99,9% случаев.
SergeyMax
01.12.2019 00:17Он не будет карту использовать потому что она с вероятностью 99,9% уже заблокирована. А если карты не блокировать — ещё как будет)
K10
Если это будет open source, то злоумышленникам dry run очень пригодится.
Они так же будут прогонять через него свои платежи и подстраивать их, чтобы антифрод не срабатывал.
chainick Автор
Ну да, классическая битва меча и щита. Только сейчас все построено на этом security through obscurity подходе, который по факту такой дырявый, что даже писать об этом страшно.
user_man
Делите функционал на общий и правила. Далее общий функционал распространяете, а правила — выборочно. Универсальные правила можно легко пускать в общую копилку, а вот специфику всякую можно придерживать, пока не станет ясно, что «это уже прошлый век».
То есть проблема вполне решаемая.
chainick Автор
Факт, уже там ниже обсуждали возможную реализацию в виде репозитория, куда имеют доступ проверенные участники системы.