Как стать автором
Обновить

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

Время на прочтение 7 мин
Количество просмотров 32K
Всего голосов 36: ↑32 и ↓4 +28
Комментарии 37

Комментарии 37

НЛО прилетело и опубликовало эту надпись здесь

Ну да, классическая битва меча и щита. Только сейчас все построено на этом security through obscurity подходе, который по факту такой дырявый, что даже писать об этом страшно.

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

То есть проблема вполне решаемая.

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

НЛО прилетело и опубликовало эту надпись здесь

Я не противник, а сторонник open source в целом и в системах, обеспечивающих безопасность в частности (и антифрод в том числе). И совсем не сторонник STO.
Но надо быть объективными: ломать чёрный ящик гораздо сложнее, чем белый при прочих равных. Почему же в криптографии по-другому? В криптографических системах а) если детали реализации не ясны, то непонятно, можно ли доверять системе, б) открытость систем позволяет привлечь к проверке на несколько порядков больше ресурсов, в) позволяет алгоритму/протоколу жить дольше конкретной реализации.
То есть польза для криптографии от открытости просто перевешивает пользу от закрытости. А для антифрода это утверждение лично мне неочевидно. И статья не убедила меня.


Ещё один момент, который нехило подкрепляет предыдущий, это ваша "идеальная система защиты от DDoS". Фишка в том, что описав эту систему вы её сразу разрушили:


  1. В вашем предложении антиDDoS слишком много от практик Spamhaus. А к этим ребятам вопросов очень много. Collateral damage там всегда на грани допустимого.
  2. Ваша система сама становится почти идеальным оружием для DoS-атак. Сделать так, чтобы ваша подсеть попала в реестр запрещённых сильно проще, чем DDoSить.
  3. Вопрос доверия и надежности такой системы решается блокчейном. Если коротко, то нет, не решается. Я не начинаю доверять реестру просто потому, что он на блокчейне.

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

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


Насчет троянского коня, которым можно завалить всю защиту — правда. Это может быть даже не специально сделано. Посмотрите на текущие реализации BGP например. Любой олень может случайно проанонсить 4 нуля в свою AS и зароутить себе полинтернета. Нужно фильтровать на бордере, т.е. нужно, чтобы участники системы не принимали бездумно все правила.


Но что если посмотреть на систему защиты с той стороны, что предлагаю я?


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


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


Не говоря уже о комьюнити, которое совместно может допиливать движок, делать какие-то новые вещи, про которые мы или не подумали или не успели сделать.


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

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

Подредактирую статью насчет этого, спасибо за обратную связь.


Почему я до сих пор не запилил репозиторий с правилами на гитхабе — пресловутый STO, как бы это ни странно звучало.


Я готов дать движок, софт очень неплохого антифрода и развивать его с комьюнили. Но отдать правила вообще всему миру, вот это вопрос.


Стоит ли так делать, или идти дальше по моей задумке, когда мы даем продукт в виде опенсорсного решения, а совместный обмен именно правилами защиты делать в более закрытом комьюнити?

Почему я до сих пор не запилили репозиторий с правилами на гитхабе — пресловутый STO, как бы это ни странно звучало.
Я нигде не писал и не подразумевал публикацию прямо на гитхабе. Я имел в виду, что "гитлабо-/гитхабо-подобный сервис" это либо локальный (на своём сервере) отдельный гитлаб с доступом для участников, либо какое-то подобное решение.

Пост подредактировал, надеюсь теперь он больше отражает то, что хотелось донести до аудитории.


Насчет интерфейса обмена правилами — по самому простому пути. ГХ/ГЛ с пулл реквестами и дальнейшим пуллом правил в локальные инсталляции, как-то так.


Спасибо, что не прошли мимо, ваши комментарии помогли лучше структурировать мысль)

Кто завтра на CyberDay в Сколково будет ?? Может вручную переговорим ?)

Что ж вы раньше не сказали) Я на конфы только докладчиком хожу, но на эту не приглашали.

А ктожзналто?
Что надо раньше.
Но !-) Я вас запомнил. Если где как пересечемся обязательно надо все лично обговорить.
P.S. Есть еще такие «Декабрьские дебаты» — посмотрите, может и это вам подойдет. Там из практиков докладчиков маловато… вы бы разбавили их своим предложением. А также посмотрите- есть замечтательные семинары (встречи в разных форматах) ACFE rus chapter: Мартынов Сергей — я думаю и публика там как раз вам ближе и народ подкованный

Учту, спасибо за инфу!

НЛО прилетело и опубликовало эту надпись здесь
«А к этим ребятам вопросов очень много. Collateral damage там всегда на грани допустимого.
Ваша система сама становится почти идеальным оружием для DoS-атак. Сделать так, чтобы ваша подсеть попала в реестр запрещённых сильно проще, чем DDoSить.»
Так и есть. Это когда щит превращают в карающий меч. Причем цель ddos атаки ДОСТИГАЕтся, а вот перезагрузка серверов и т.д. к освобождению атакованного хоста неприменима. Придется долго и нудно объясняться с админами всей системы для разблокировки. В итоге ущерб от такой отбитой атаки будет превосходить ущерб от прямой ddos на порядок

Да, это уязвимости открытой системы, к которыми нужно придумать противодействие. Но не так все плохо, я не призываю бездумно принимать правила, которые говорят "заблокируем все кредитные карты".


Во-первых пресловутый dry-run, который позволит оценить результат применения правил без деплоя их на прод.


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


Более того, уже сейчас есть рассылки типа fin-cert, в которых регулярно присылают маскированные паны дропов и прочий скам. Тут предложение централизовать это в более автоматизированном и централизованном виде, плюс универсальный софт, который позволит сделать это с минимальными усилиями.

Считали ли эффективность системы с правилами и ml против системы с чистым ml? Я к тому, что кожаные мешки все ещё придумывают правила потому, что так исторически сложилось/руководители не доверяют машине/придумывальщики хорошие ребята, и не хотят из выгонять, или реально машина пока недотягивает, и roc/auc гибридной белково-кремниевой системы реально выше?

Самая большая проблема — это платежная конверсия vs защита от фродов. Идеальный антифрод, который дает вам 100% гарантию — это тот, который деклайнит 100% платежей, но бизнес такого не оценит.


Из этого вытекает проблема ML. Почему этот черный ящик отклонил платеж или зароутил его в терминал, покрывающий высокий риск (а там 3DS, убитая конверсия, вот это все)?


С правилами гораздо проще и понятнее, сразу видно, почему.


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

Разрабатывал две разные системы антифрода для двух разных компаний. Когда дело доходило до ML — каждый раз становилось понятно, что проблема здесь очень не простая. В том смысле, что 1) данных о транзакции у нас не так уж и много, 2) ошибки в сторону отклонения добропорядочных транзакций стоят дорого и 3) достать достаточно достоверные данные в достаточном количестве для обучения нейросети (если брать нейросеть) почти нереально.

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

Мне повезло больше с ML в антифроде (даже был удивлен, как можно быстро первый результат получить), правда, тема не связанная с чаржбеками, и да, цель была именно решить проблему, а не продать кому-то что-то за счет хайпа, но, как-то, нейросети даже мы не то, чтобы тестировали, а даже и мысли не было использовать.

А какая была задача если не секрет?

Интересно было почитать. Спасибо!
Жду продолжения статьи.

Вы готовы поделиться своей разработкой антифрода совершенно бесплатно?
Вы готовы поделиться своей разработкой антифрода совершенно бесплатно?

Да.

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

Ага. Только не бесплатного, а опенсорсного. Все-таки инфраструктуру и вычислительные мощности мы не предоставляем.

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

"С банками можно работать по такой же схеме. Есть общий список антифрод-шаблонов, который расходится по всем банкам."


Насколько я знаю, сейчас ведь что-то в этом роде и есть. ФинЦЕРТ формирует, так называемый, Фид-Антифрод. В нем, правда, не шаблоны, а черный список карт/документов/счетов и т.д. Но все это не в виде рассылки, а можно получать по API.

Да, я про него писал выше. Там даже не суть в том что по апи, а в том что данные устаревают еще до попадания в этот список. Дроп снял с карты и второй раз ее использовать не будет, блокировать бессмысленно в 99,9% случаев.

Он не будет карту использовать потому что она с вероятностью 99,9% уже заблокирована. А если карты не блокировать — ещё как будет)

Летом говорил про подобное Морейнису. Он не заинтересовался. И вот — на тебе (((
Идея классная, но она всё равно остаётся лишь полумерой. Только OSS тут мало, нужно кое-что ещё.

С Морейнисом не знаком. А чего еще не хватает, поделитесь секретом?

Так а где исходники то ?)
Простите, как-то пропустил
Зарегистрируйтесь на Хабре , чтобы оставить комментарий