Антифрод

Антифрод сервис по поиску и нивелированию случаев эксплуатации других, общедоступных сервисов Яндекса. Три года назад мы начали проектировать платформу, позволяющую быстро и легко развернуть антифрод где угодно в компании. Сложность задачи в том, что многим сервисам нужны максимально строгие гарантии по скорости, надежности и качеству; часть из них оперирует очень большими объемами данных. Команде антифрода, в свою очередь, важна гибкость системы, простота поддержки и выразительность факторов, на которых будет строиться машинное обучение.


Руководитель антифрода Андрей Попов выступил с докладом о том, как мы смогли выполнить все эти противоречивые требования. Центральная тема доклада модель вычисления сложных факторов на потоке данных и обеспечение отказоустойчивости системы. Также Андрей кратко описал следующую, еще более быструю итерацию антифрода, которую мы сейчас разрабатываем.

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

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

Что такое антифрод?

Что вообще такое антифрод? Думаю, проще всего показать.

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

С чем вообще борется антифрод? Пара примеров.

Например, имитация действий пользователя. Этим занимаются ребята, которых мы называем черные SEO, те, кто не хочет улучшать качество сайта и контент на сайте. Вместо этого они пишут роботов, которые ходят на поиск Яндекса, кликают по их сайту. Они расчитывают, что так их сайт поднимется выше. На всякий случай напоминаю, что такие действия противоречат пользовательскому соглашению и могут привести к серьезным санкциям со стороны Яндекса.



Или, например, накрутка отзывов. Такой отзыв можно увидеть у организации на Картах, которая ставят пластиковые окна. За этот отзыв она же сама и заплатила.

Верхнеуровнево архитектура антифрода выглядит так: некоторый набор сырых событий попадают в саму система антифрод как в черный ящик. На выходе из него генерируются размеченные события.

У Яндекса много сервисов. Все они, особенно большие, так или иначе сталкиваются с разными видами фрода. Поиск, Маркет, Карты и десятки других.

Где мы были еще года два-три назад? Каждая команда выживала под натиском фрода как могла. Она генерировала свои команды антифрода, свои системы, которые не всегда работали хорошо, были не очень удобны для взаимодействия с аналитиками. И главное, они были слабо проинтегрированы между собой.

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



Зачем нам нужна единая платформа? Переиспользование опыта и данных. Централизация опыта и данных в одном месте позволяет быстрее и качественнее реагировать на крупные атаки они обычно бывают кросс-сервисными.

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

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

Расскажу немного про то, как мы классифицируем антифроды.



Это может быть офлайн-система, которая считает часы, дни и тяжелые офлайн-процессы: например, сложные кластеризации или сложное переобучение. Этой части я практически не буду касаться в докладе. Есть near real-time-часть, которая работает за единицы минут. Это некая золотая середина, у нее быстрая реакция и тяжеловесные методы. В первую очередь я остановлюсь на ней. Но не менее важно сказать, что на этом этапе мы используем данные с этапа уровнем выше.

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

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

Я практически не буду касаться самих ML-методов. В основном я буду рассказывать о платформах, создающих фичи, которые мы потом используем в обучении.

Кому это может быть интересно? Очевидно, тем, кто пишет антифрод или борется с мошенниками. Но также и тем, кто просто запускает поток данных и считает фичи, считает ML. Так как мы сделали достаточно общую систему, может быть, что-то из этого вам будет интересно.

Какие у системы требования? Их достаточно много, вот некоторые из них:

Большой поток данных. Мы обрабатываем сотни миллионов событий за пять минут.
Полностью конфигурируемые фичи.
Декларативный язык описания факторов.
Конечно же, кросс-ДЦ и exactly-once-обработка данных, которая нужна для некоторых сервисов. Удобная инфраструктура как для аналитиков, которые подбирают итоговые фичи, обучают модели и подобное, так и для разработчиков, которые поддерживают систему.
И, конечно, скорость.

Дальше расскажу про каждый из этих пунктов в отдельности.

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

Все совпадения с реальными сервисами, естественно, случайны. Рассмотрим в первую очередь near real-time-версию, так как онлайн конкретно здесь не нужен при первом приближении.

Большие данные

В Яндексе есть классический способ решения проблем с большими данными: использовать MapReduce. Мы используем нашу собственную реализацию MapReduce, называется YT. Кстати, у Максима Ахмедова сегодня вечером рассказ про нее. Вы можете использовать вашу реализацию либо опенсорсную реализацию вроде Hadoop.

Почему мы сразу не используем онлайн-версию? Она не всегда нужна, может усложнять пересчеты в прошлое. Если мы добавили новый алгоритм, новые фичи, мы хотим часто пересчитать данные в прошлое, чтобы изменить вердикты по ней. Сложнее использовать тяжеловесные методы думаю понятно, почему. И онлайн-версия по ряду причин может быть более требовательна по ресурсам.

Если мы используем MapReduce, получается примерно такая схема. Мы используем некий минибатчинг, то есть делим на максимально маленькие куски батчей. В данном случае это одна минута. Но те, кто работает с MapReduce, знают, что меньше этого размера, наверное, уже возникают слишком большие оверхеды самой системы накладные расходы. Условно, она не сможет справляться с обработкой за одну минуту.

Дальше мы над этим набором батчей запускаем набор Reduce и получаем размеченный батч.



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

Почему не использовать методы приблизительного подсчета? Короткий ответ: мы их тоже используем, но иногда в задачах антифрода важно иметь именно точное значение за какие-то интервалы. Например, разница между двумя и тремя прочитанными книгами может быть весьма существенна для тех или иных методов.

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



Давайте попробуем в лоб. У нас есть одна минута и большая старая история. Мы пускаем ее на вход Reduce и на выход выдаем обновленную историю и размеченный лог, данные.

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



Заменим это на некий key-value store. Это вновь наша собственная реализация, key-value-хранилище, но она хранит данные в памяти. Наверное, ближайший аналог какой-нибудь Redis. Но у нас тут получается небольшое преимущество: наша реализация key-value store очень сильно проинтегрирована с MapReduce и кластером MapReduce, на котором это запускается. Получается удобная транзакционность, удобная передача данных между ними.

Но общая схема что мы в каждом джобе этого Reduce будем ходить в этот key-value storage, обновлять данные и записывать обратно после формирования вердикта по ним.

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

Конфигурируемые фичи

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

Давайте разобьем на три этапа:
Extract, где мы изымаем данные для данного ключа и из лога.
Merge, где мы сливаем эти данные со статистикой, которая находится в истории.
Build, где мы формируем итоговое значение фичи.

Давайте, например, посчитаем процент детективов, прочитанных пользователем.



Если пользователь читает слишком много детективов, он слишком подозрительный. Никогда непонятно, чего от него ждать. Тогда Extract изъятие количества детективов, которые прочел пользователь в этом батче. Merge взятие всех детективов, всех этих данных из батчей за месяц. И Build это какая-то сумма.

Затем мы то же самое делаем для значения всех книг, которые он прочитал, и в итоге получаем деление.

А если мы хотим посчитать разные значения, например, количество различных авторов, которых читает пользователь?





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



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

Давайте, например, введем вот такие разрезы пользователь, автор и жанр.



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

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

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



Тогда посчитаем среднее значение по авторам, которые связаны за большой интервал. И тогда здесь среднее значение опять же достаточно низкое: 3. Этот автор нам почему-то кажется подозрительным.



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

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

Как это сделать в парадигме MapReduce? Давайте сделаем несколько последовательных редьюсов и зависимости между ними.



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

Построим, например, такой граф.



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

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

Здесь важно, что у нас нет вот такой зависимости:



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

А как в этом сделать трехстадийную статистику, которую я приводил выше, если у нас всего два этапа? Очень просто. Мы можем считать первое значение на первом этапе батча N.



Второе значение на первом этапе батча N+1, и итоговое значение нужно считать на втором этапе батча N+1. Таким образом, при переходе между первым этапом и вторым будут, может быть, не совсем точные статистики для батча N+1. Но обычно этого достаточно для подобных расчетов.



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



К этому добавляется то, что мы называем отношениями между событиями. Часто у нас в логах или в данных, которые нам посылаются, появляются дубликаты. Это могут быть либо технические события, либо роботное поведение. Мы такие дубликаты также обнаруживаем. Или, например, какие-то связанные события. Скажем, у вас в системе показываются рекомендации книг, и пользователи кликают по этим рекомендациям. Чтобы итоговые статистики, которые влияют на ранжирование, не портились, нам нужно следить, что если мы отфильтруем показ, то должны отфильтровать и клик по текущей рекомендации.

Но так как поток у нас может приходить неравномерно, сначала клик, то мы должны его отложить до момента, пока мы не увидим показ и не примем вердикт на его основе.

Язык описания фич

Расскажу немного про язык описания всего этого.



Можно не вчитываться, это для примера. Начинали с трех основных компонент. Первое описание единиц данных в истории, вообще говоря, произвольного типа.



Это какая-то фича, nullable-число.



И какое-то правило. Что мы называем правилом? Это набор условий на этих фичах и что-то еще. Было у нас три отдельных файла.

Проблема в том, что тут одна цепочка действий разнесена по разным файлам. С нашей системой нужно работать большому количеству аналитиков. Им было неудобно.

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

Решение давайте сделаем свой DSL. Он более понятно описывает наш сценарий, он проще для новых людей, он более высокоуровневый. Вдохновение мы брали у SQLAlchemy, C# Linq и подобного.

Приведу пару примеров, аналогичных тем, которые я приводил выше.



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



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



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



К этому мы потом можем добавить условие фильтрации. То есть фильтр у нас может быть, например, таким: лояльность не слишком высокая и количество процентов детективов между 80 из 100.

Что мы для этого используем под капотом?



Под капотом мы используем самые современные технологии, напрямую из 70-х годов, такие как Flex, Bison. Может быть, слышали. Они генерируют код. У нас файл с кодом проходит через наш лексер, который сгенерирован во Flex, и через парсер, который сгенерирован в Bison. Лексер генерирует терминальные символы или слова в языке, парсер генерирует синтаксические выражения.

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

Что в итоге? Это сложнее, чем может показаться с первого взгляда. Нужно потратить много ресурсов, продумать такие мелочи, как приоритеты операций, крайние случаи и подобное. Нужно изучить редкие технологии, которые вряд ли вам пригодятся в реальной жизни, если вы не пишете компиляторы, конечно. Но в итоге это того стоит. То есть если у вас, как и у нас, большое количество аналитиков, которые часто приходят их других команд, то в итоге это дает существенное преимущество, потому что им становится проще работать.

Надежность

Некоторые сервисы требуют отказоустойчивости: кросс-ДЦ и exactly-once-обработку. Нарушение может вызывать расхождение статистик и потери, в том числе денежные. Наше решение для MapReduce такое, что мы считаем данные в каждый момент времени только на одном кластере и синхронизируем их на второй.



Например, как бы мы вели себя здесь? Есть лидер, follower и message broker. Можно считать, что это условная кафка, хотя тут, конечно, собственная реализация.



Мы доставляем наши батчи на оба кластера, запускаем на одном в лидере набор редьюсов, принимаем итоговые вердикты, обновляем историю и передаем результаты обратно сервису в message broker.

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

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

Почему бы вообще не считать на двух кластерах параллельно? Внешние данные могут отличаться на двух кластерах, поставлять их могут внешние сервисы. Что вообще такое внешние данные? Это что-то, что с вот этого более высокого уровня поднимается. То есть сложные кластеризации и подобное. Либо просто вспомогательные для расчетов данные.

Нам нужно согласованное решение. Если мы будем параллельно считать вердикты с использованием разных данных и периодически переключаться между результатами из двух разных кластеров, согласованность между ними будет сильно падать. И, конечно же, экономия ресурсов. Так как мы в каждый момент времени используем ресурсы CPU только на одном кластере.

А что со вторым кластером? Когда мы работаем, он практически простаивает. Давайте использовать его ресурсы для полноценного препрода. Под полноценным препродом я тут подразумеваю полноценную инсталляцию, которая принимает тот же поток данных, работает с теми же объемами данных и т. д.



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

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

(00:25:12)

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

К этому добавляются преимущества B2B-тестирования. То есть мы все выкатываем, естественно, сначала на препрод. Полностью сравниваем любые отличия, и, таким образом, не ошибемся, минимизируем вероятность, что мы можем ошибиться при выкатке на прод.

Немного про планировщик. Понятно, что у нас есть какие-то машины, которые запускают задачу в MapReduce. Это некие воркеры. Они регулярно синхронизируют свои данные в Cross-DC Database. Это просто состояние того, что они успели посчитать на данный момент.



Если воркер становится недоступен, то другой воркер пытается захватить лог, забрать состояние.



Переподняться с него и продолжить работу. Продолжить ставить задачи на этом MapReduce.



Понятно, что в случае переподнятия этих задач, некоторое множество из них может перезапуститься. Поэтому здесь есть очень важное свойство для нас: идемпотентность, возможность перезапускать каждую операцию без последствий.

То есть весь код должен быть написан так, чтобы это нормально работало.



Немножко расскажу про exactly-once. Мы выносим вердикт согласованно, это очень важно. Используем технологии, которые дают нам такие гарантии, и мониторим, естественно, все расхождения, сводим их к нулю. Даже когда кажется, что это уже сведено, периодически возникает очень хитрая проблема, которую мы не учли.

Инструменты

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



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



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



Что мы вообще мониторим? Очевидно, лаг системы крайне важен. Очевидно, время работы каждой отдельной стадии и, конечно же, фильтрация отдельных правил. Это бизнесовое требование.

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

Скорость

Расскажу про переход в онлайн-часть. Тут проблема в том, что лаг в полноценном контуре может достигать единиц минут. Это в контуре на MapReduce. В некоторых случаях нам нужно банить, обнаруживать мошенников быстрее.

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



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

В такой схеме может возникнуть следующая проблема.



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

Тогда мы из этого key-value storage считаем данные на оба воркера из истории, мы его обновим по-разному и возникнет гонка при попытке записать обратно.

Решение: давайте сделаем предположение, что можно разделить чтение и запись, что запись может происходить с небольшой задержкой. Обычно это не сильно важно. Под небольшой задержкой я здесь подразумеваю единицы секунд. Это важно, в частности, по той причине, что наша реализация этой key-value store занимает больше времени на запись данных, чем на чтение.

Будем обновлять статистики с отставанием. В среднем это работает более-менее хорошо, с учетом того, что мы будем хранить на машинах кэшированное состояние.



И другая вещь. Для простоты сольем вот эти истории в одну и пошардируем ее по типу и по ключу разреза. У нас есть какая-то единая история.

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

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



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

Здесь у него меняется его предназначение. Он больше не принимает вердикты. Вместо этого он просто принимает updates из Reader, смешивает их и правильно применяет к истории.

Понятно, что здесь нужна компонента, координатор, которая распределяет эти updates между ридерами и райтерами.

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



Что мы вообще получили? Аналитики стали делать работу быстрее и одинаково для всех сервисов. Это повысило качество и связанность всех систем. Можно переиспользовать данные между антифродами разных сервисов, а новые сервисы получают качественный антифрод быстро.



Пара мыслей в конце. Если вы будете писать нечто подобное, сразу подумайте про удобство аналитиков в части поддержки и расширяемости данных систем. Делайте конфигурируемым все что можно, это вам понадобится. Иногда свойств кросс-ДЦ и exactly-once бывает сложно достичь, но можно. Если вам кажется, что уже достигли, перепроверьте. Спасибо за внимание.

Привет, Хабр.

Вы не задумывались о таком обстоятельстве, что век пользовательской криптографии безвозвратно уходит. Нет, я не о том, что шифрование мессенджеров и криптовалюты сегодня в опале. Я о старом добром ДБО, проще говоря о системах банк-клиент. Еще каких-то 10 лет назад любой уважающий себя банк-клиент состоял из софта и токена с цифровой подписью. А сегодня это уже практически раритет, все повсеместно переходят на смс-подтверждения, что безусловно на порядок удобнее чем возня с настройками крипто-провайдеров и установками сертификатов ЦП.

В чем же дело, неужели удобство перевесило безопасность в такой сфере как финансы? А вот и нет, оказывается, что безопасность обоих вариантов одинаково низкая. Как же так, ну понятно смс аутентификация далеко не идеал безопасности с возможностью перехвата и подмены смсок, но крипта да еще и в аппаратном носителе! Всё дело в том, что любая система безопасности оценивается по её самому слабому звену.

Алиса и Боб

Опишу проблему на примере Алисы и Боба. Представьте, что в одной руке у Алисы смартфон, на экране которого выведен какой-либо платежный документ. А в другой руке беспроводной токен с цифровой подписью. Алисе предстоит подписать электронную платежку, для этого достаточно сопрячь токен и смартфон и кликнуть подписать.

Как будто все достаточно просто и безопасно оба устройства принадлежат Алисе и оба в её руках. Но допустим есть Боб, который решает в этот момент перехватить Алисин документ и направить в её токен другой документ например платежку, в которой со счета Алисы уйдет крупная сумма на неизвестный счет.



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

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

Об антифроде

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

MITM, точнее MID

Таким образом мы имеем разновидность угрозы человек посередине Man In The Middle (MITM). В данном случае посередине между экраном смартфона и токеном с цифровой подписью. Но в отличие от классической атаки человек посередине нейтрализовать её криптографическими методами невозможно. Не знаю имеет ли данный вид атаки свой специфический термин, мы назвали её человек в устройстве Man In Device (MID). Далее по тексту буду именно так называть данную атаку.

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

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

Что есть на рынке?

Существуют ли сегодня способы и устройства для нейтрализации атаки Man In Device? Да такие устройства существуют, это пользовательские терминалы класса Trust Screen.

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

С такой установкой 1,5 года назад мы начали мозговой штурм в поисках нового решения угрозы Man In Device.

Вернемся к Алисе и Бобу

Для наглядности найденного решения еще раз возвратимся к модели угрозы с Алисой и Бобом. Итак, Алиса по прежнему держит в одной руке смартфон, неважно какой марки и модели и неважно с какой операционной системой. Назовем его не доверенным устройством. В другой руке Алиса держит некое устройство с цифровой подписью, будем считать, что это сертифицированное доверенное устройство, произведенное по всем канонам информационной безопасности и Бобу не под силу взломать данное устройство Алисы. Но Боб без труда проник в смартфон Алисы и готов реализовать на нем атаку Man In Device.

Вы можете заметить, что пока ситуация ничем не отличается от той, что была описана выше, в которой Боб с легкостью проворачивает мошенничество с подменой документа. Где же решение?
Найденное решение, названное нами эффектом доверенного просмотра не обезвреживает данные атаки, но позволяет гарантированно подтвердить, что на экране смартфона демонстрируется правильный документ. Этот принцип схож с идеей квантовой криптографии в которой канал связи не защищается, но стороны гарантированно могут определить попытку перехвата ключа. Так и в нашей технологии мы не беремся объять необъятное в попытке защитить каналы связи, операционную систему, процессор и т.д., но наше решение способно гарантированно определить факт подмены или изменения электронного документа на любых не доверенных устройствах, будь то смартфон или персональный компьютер.

Чтобы понять, как работает наша технология еще раз представим, что для подписания документа файл с документом пересылается из смартфона в доверенное устройство. Но по пути движения документа у злоумышленника есть масса способов заменить документ или данные в нем. И здесь возникает главный вопрос. Как убедиться, что миниатюрное доверенное устройство, не имеющее экрана для отображения принятого документа получило правильный документ? В нашем решении мы обратно пересылаем из доверенного устройства документ и заново выводим его изображение на экран смартфона, но снабдив изображение документа в доверенном устройстве определенными защитными метками, сгенерированными особым образом. Разработанная технология создает эффект доверенного просмотра за счет принципов визуальной криптографии экзотического направления в области современной криптографии.

О визуальной криптографии

Один из самых известных методов принадлежит Мони Наору и Ади Шамиру, разработавшим его в 1994 году. Они продемонстрировали графическую схему с разделением секрета, согласно которой изображение было разделено на n частей так, что только человек, имеющий все n частей мог расшифровать изображение, в то время как остальные n-1 части не показали никакой информации об оригинальном изображении.


Соединение разделенных секретов позволяет увидеть скрытую информацию


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

здесь спрятано 3 секрета

Разберем криптосхему алгоритма

Исходный текст состоит из трех черно-белых изображений, каждый пиксель либо 0 прозрачный, либо 1 черный.

При наложении изображений друг на друга пиксели сливаются по следующему принципу:

1) 0 + 0 + 0 = 0
2) 1 + 0 + 0 = 1 или 0 + 1 + 0 = 1 или 0 + 0 + 1 = 1
3) 1 + 1 + 0 = 1 или 1 + 0 + 1 = 1 или 0 + 1 + 1 = 1
4) 1 + 1 + 1 = 1

Таким образом слияние изображений приводит к утрате части информации (строки 2 и 3) что не позволит без ключа восстановить каждое из изображений по отдельности. Так происходит этап шифрования.

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

Например, перед нами три фрагмента исходных изображений, накладываемых друг на друга:



Зашифрованный фрагмент изображения содержит пиксели черного и прозрачного цвета и имеет меньший объем информации по сравнению с тремя исходными изображениями.

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

В приведенном примере получится следующий ключ:

a1:110,c2:011,d2:111,b4:010,a5:110,c5:111

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

Данный крипто алгоритм по сути является односторонней функцией с ключом.

О криптостойкости

Давайте посчитаем крипто стойкость данного алгоритма. Каждый пиксель черного цвета является результатом слияния пикселей трех слоев. При этом как было показано выше существует 7 вариантов такого слияния, приведу их еще раз:



Таким образом в небольшом фрагменте изображения, приведенном в примере, состоящем из 6 пикселей черного цвета существует 6 в 7-й степени или 279 936 вариантов разложения на исходные картинки.

Несложно прикинуть, что если на полноформатном изображении таких пикселей окажется, например, 1000, то количество вариантов составит 1000 в 7-й степени или
1 000 000 000 000 000 000 000 вариантов.

Понятно, что при данной крипто стойкости прямой метод взлома невозможен. Но у потенциального взломщика есть другие методы криптоанализа.

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

Во-вторых, капча смешана с изображением защитной сетки, имеющей случайный узор и текстом документа.

И в-третьих, времени на попытку распознавания у злоумышленника крайне мало, 1-2 секунды. Именно столько времени должно пройти с момента нажатия кнопки пользователем на доверенном устройстве и появлением изображения на экране не доверенного устройства.


Попробуйте распознать кодовое слово, смешанное с защитной сеткой и частью текста документа


Этот же фрагмент после того, как слой с защитной сеткой частично обесцвечен кодовое слово распознается без труда

Все ли так гладко?

Однако обзор представленной технологии был бы неполным, если не упомянуть о потенциальной лазейке, которую мог бы использовать хакер. Дело в том, что один из трех слоев на едином изображении заранее известен злоумышленнику Бобу это изображение с текстом документа. Естественно, что у Боба также есть изображение и своего документа, которым он собирается подменить документ Алисы. И далее задача Боба может быть значительно упрощена. Зная один из трех секретов в виде слоя с изображением текста можно из единого изображения вычесть маску с изображением данного секрета. В итоге останется изображение, включающее в себя 2 слоя с защитной сеткой и кодом подлинности. После чего полученное изображение смешивается с изображением текста оригинального документа. И все задача взлома решена.

Правда здесь все не так просто: на тех участках, где пиксели текста перемешаны с пикселями защитной сетки и/или кода подлинности после вычитания маски останутся видимые разрывы. Но если оригинальный текст отличается от фальшивого небольшим количеством символов на локальном фрагменте, то после наложения остаточного изображения защитной сетки с кодом подлинности на оригинальный текст данные разрывы на большинстве участков исчезнут и останутся лишь на небольшом фрагменте, где осуществлена подмена. Так что Алиса может и не заметить подмену документа.

Решение

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

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


плавное обесцвечивание защитной сетки позволяет убедиться, что текст документа при этом не меняется

Для простоты понимания приведен пример с черно-белыми изображениями. Но при определенной модификации алгоритма его можно применить и к цветным изображениям.

Теперь пару слов о роли пользователя в данной технологии. Использование в технологии методов визуальной криптографии подразумевает использование зрения пользователя в качестве основной метрики для оценки отсутствия или наличия атаки Man In Device. По сути речь идет о визуальной валидации, которая выражается в двух последовательных операциях, совершаемых пользователем:

1. сравнении кода подлинности на индикаторе доверенного устройства с кодом подлинности в капче на изображении документа


в качестве доверенного устройства предлагается создать специальную пластиковую карту
с индикатором кода подлинности и кнопками подтвердить и отменить

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

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

Именно визуальная валидация создает конечный эффект доверенного просмотра.

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

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



Ежегодный ущерб от финансового мошенничества в сфере онлайн платежей составляет 200 млрд. $. 38% из них результат хищения личных данных пользователей. Как избежать подобных рисков? Помогают в этом антифрод системы.

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

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

На сегодняшний день банковский сектор постепенно обновляет парк устаревших антифрод систем более новыми, которые созданы с использованием новых и усовершенствованных подходов, методик и технологий, таких как:

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

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

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

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

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

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

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

На сегодняшний день на рынке антифрод систем есть ряд известных решений:

ThreatMark

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

NICE

Решение Nice Actimize от компании NICE относится к классу аналитических платформ и позволяет осуществлять выявление финансового мошенничества в режиме реального времени. Система обеспечивает защиту любых типов платежей, в том числе SWIFT/Wire, Faster Payments, платежи BACS SEPA, банкоматные/дебетовые транзакции, массовые платежи, платежи по счетам, P2P/почтовые платежи и различные формы внутренних переводов.

RSA

RSA Transaction Monitoring and Adaptive Authentication от компании RSA относится к классу
аналитических платформ. Система позволяет выявлять попытки мошенничества в режиме реального времени и производит мониторинг транзакций после входа пользователя в систему, что позволяет защититься от атак типа MITM (Man in the Middle) и MITB (Man in the Browser).

SAS

SAS Fraud and Security Intelligence (SAS FSI) представляет собой единую платформу для решения задач предотвращения транзакционного, кредитного, внутреннего и иных типов финансового мошенничества. Решение совмещает тонкую настройку бизнес-правил с технологиями машинного обучения для предотвращения мошенничества при минимальном уровне ложных срабатываний. Система включает встроенные механизмы интеграции с онлайн- и офлайн-источниками данных.

F5

F5 WebSafe это решение по защите от киберугроз в финансовой сфере от компании F5. Оно позволяет выявлять кражу учетных записей, признаки заражения вредоносными программами, кейлоггинга, фишинга, троянов удаленного доступа, а также атак типа MITM (Man in the Middle), MITB (Man in the Browser) и MITP (Man in the Phone взлом мобильных устройств).

IBM

IBM Trusteer Rapport от компании IBM предназначена для защиты пользователей от перехвата учетных данных, захвата экрана, вредоносных программ и фишинговых атак, в том числе атак типа MITM (Man in the Middle) и MITB (Man in the Browser). Для этого в IBM Trusteer Rapport применяются технологии машинного обучения, что позволяет автоматически обнаружить и удалить вредоносные программы с конечного устройства, обеспечив безопасность сеанса работы в режиме онлайн.

Guardian Analytics

Система Digital Banking Fraud Detection от компании Guardian Analytics относится к аналитическим платформам. При этом Digital Banking Fraud Detection защищает от попыток захвата аккаунта клиента, мошеннических переводов, фишинга и атак типа MITB (Man in the Browser) в режиме реального времени. Для каждого пользователя создается свой профиль, на основе которого происходит распознавание аномального поведения.



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

Автор: Артемий Кабанцов, Softprom

Ни для кого не является секретом, что на популярных площадках Авито, Юла и т.п. распространены мошеннические схемы, созданные для выманивания тем или иным способом денег с доверчивых покупателей и продавцов.

В последнее время получили широкое распространение целые группировки мошенников, работающие по модели мошенничество как услуга (Fraud-as-a-Service). Эти группировки объединяют в своих рядах организаторов (ТС), поддержку (саппорт) и рядовых участников (воркеров).

Организаторы обеспечивают функционирование сервисов (каналы/чаты/боты в Telegram, фишинговые сайты, обработка платежей, отмыв и вывод средств), привлекают воркеров через рекламу на теневых форумах, предоставляют поддержку и забирают себе комиссию с каждого платежа.

Саппорт помогают (дают советы и рекомендации, а также сами подключаются к общению при необходимости) воркерам обманывать жертв.

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

На данный момент группировки работают по двум основным типам мошеннических схем:

• Старая схема, когда мошенник (воркер) представляется продавцом и обманывает покупателя, уговаривая его перейти по присланной в сторонний мессенджер (часто WhatsApp или Telegram) фишинговой ссылке и заплатить (ввести данные платежной карты) за несуществующий товар.
• Схема 2.0, когда мошенник (воркер) представляется покупателем и обманывает продавца, уговаривая его перейти по присланной в сторонний мессенджер (часто WhatsApp или Telegram) фишинговой ссылке и введя данные платежной карты якобы получить на нее перевод с несуществующего депозита (т.н. безопасная сделка).

Существуют версии схем 3.0 и даже 4.0, но они занимают не существенную долю в общем объеме мошеннических транзакций.

Подробнее про мошеннические схемы и внутреннее устройство группировок можно прочитать на Хабре в статье Как Авито выявляет мошенников и борется с фродом.

Нами проанализировано 116 активных группировок из чуть более 200 всего существующих на данном рынке. В 59-и из них больше 100 участников (воркеров), а в 13-и более 1,000. В самой крупной по количеству выплат группировке состоит около 800 воркеров.

Все данные для анализа собирались нами путем парсинга открытых и закрытых Telegram-каналов мошеннических группировок за период с октября 2019 года по октябрь (включительно) 2020 года. Данные каналы предназначены для воркеров, и в качестве гарантий отсутствия махинаций с выплатами со стороны организаторов публикуют в режиме близком к реальному времени все снятия (транзакции) с платежных карт жертв.

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

И так, перейдем непосредственно к самому интересному к цифрам. За анализируемый период во всех мошеннических каналах:

• Количество транзакций: 111,021
• Общая сумма всех транзакций: 666,046,958 руб.

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

• Средняя сумма одной транзакции: 5,999 руб. (медиана: 4,000 руб.)
• Максимальная сумма одной транзакции: 200,000 руб. (прямой перевод с карты на карту)
• Максимальное снятие с карты одной жертвы (суммарно за несколько транзакций): 2,100,000 руб. (21 транзакция по 100,000 руб.)

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

• Всего активных воркеров: 13,107
• Среднее число транзакций у одного воркера: 6 (медиана: 3)

Активность воркеров в зависимости от дня недели. Наибольшую активность воркеры проявляют в начале недели.

• Максимальное число транзакций у одного воркера: 488
• Всего получено воркерами: 468,674,726 руб.

Активность воркеров в течении дня. Закономерно, что активность воркеров снижается в ночное время (на графике московское время) и особенно общее снижение активности заметно в выходные дни.

• Средний заработок одного воркера за весь период: 28,246 руб. (медиана: 9,905 руб.)
• Максимальный заработок одного воркера за весь период: 1,529,062 руб.
• Средний заработок организаторов одной группировки за весь период: 1,810,754 руб. (медиана: 246,640 руб.)
• Максимальный заработок организаторов одной группировки за весь период 22,468,352 руб.
• Площадка с максимальным числом мошеннических транзакций: Авито (55,589 транзакций)
• Площадка с максимальной суммой мошеннических транзакций: Авито (306,435,112 руб.)

Распределение мошеннических транзакций по площадкам. Всего были выявлены мошеннические транзакции по 38 площадкам, при этом общая доля 34 из них не превышает 6%. По 21 площадкам выявлено менее 100 мошеннических транзакций на общую сумму 2,496,100 руб. Следует учитывать, что есть транзакции, которые попали в общую статистику (и по сумме и по количеству), но не попали в статистику той или иной площадки.

Новости про утечки информации и аналитику по теневым форумам всегда можно найти на Telegram-канале Утечки информации.

Прежде чем строить антифрод, надо понять, каким на сервисе бывает фрод какие методы злоумышленники выбирают, чтобы получить выгоду и навредить пользователям. Алексей Савостин поделился опытом Яндекс.Маркета в исследовании способов фрода, рассказал о целях (порой изощрённых), которые преследуют фродеры, и о данных, по которым можно определять подозрительную активность.

Всем привет, меня зовут Алексей Савостин. Я занимаюсь направлением антифрода в Яндекс.Маркете и сегодня расскажу, как мы строили антифрод для маркетплейса Беру, который с октября стал частью Маркета. (...)

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

Расскажу подробнее о том, какие направления есть у фрода маркетплейса и какие источники убытков существуют.



Самое крупное направление реселлеры, дальше идут магазины конкурентов, пункты самовывоза и кардеры.

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

Фрод скидок и бонусов. Реселлеры, нарушая правила сервиса, регистрируют большое количество аккаунтов и пытаются разбить заказы на очень мелкие, выкупая товары с максимальными скидками, маркет-бонусами (это акции, привязанные к конкретному заказу) и используя различные кэшбэк-сервисы.

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

Резерв стоков. Были случаи, когда товары попадали в акцию с большой скидкой, реселлеры без оборотных средств делали закупки с разных аккаунтов, используя ПВЗ Маркетплейса либо партнеров как склады.

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

Недобросовестные конкуренты, которые хотят чаще попадать на карточку товара, могут отправить товар других поставщиков в Сибирь или на Дальний восток, а у нас и у наших партнеров есть ограниченное количество товаров на складе. Почему это так работает? Есть набор поставщиков, которые хотят продать свой товар на маркетплейсе. У каждого поставщика есть определенная цена, с которой он готов работать и выставляться в магазине. У кого-то цена может быть выше, у кого-то ниже из-за большого оборота этих товаров и запасов на складе.

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

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

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

Как ведут себя фродеры по этим трем направлениям? Практически все они ведут себя примерно схоже и пытаются спрятаться одинаково, за исключением реселлеров. Но реселлеры в нашем конкретном кейсе используют эмуляторы Android и вторые пространства Android, чтобы получить больше бонусов. Это скорее наш внутренний кейс. Чтобы получить бонус, надо скачать наше приложение. Фактически все остальные направления у всех видов фродеров одинаковые они пытаются регистрировать очень много новых аккаунтов, представляясь разными лицами; использовать VPN, режим инкогнито, вымышленные имена и адреса доставки.



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

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

Что мы делаем, чтобы противоборствовать фродерам?

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



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

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

Как это выглядит на схеме:



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

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

Если это злонамеренные действия и мы определили фрод, возможно применение мер противодействия, таких как блокировка аккаунта и отмена заказов, которые созданы с нарушением правил сервиса и в будущем повлекут убытки для наших партнеров либо для маркетплейса.

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

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



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

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

Близость телефонных номеров и почтовых адресов. Фродеры часто используют одни и те же адреса, потому что эти ПВЗ для них удобны, они делают много заказов на один адрес либо на очень близкие. А так как товарные категории тоже будут близки, это можно достаточно просто обнаружить.

Как я уже сказал в предыдущем пункте, смотрите на всплески по редким товарам.

Отдельные блоки советов: хватайте все данные, до которых можете дотянуться. Смотрите на логи, получайте данные от ваших приложений о том, эмуляторы это или виртуалки. Собирайте все данные, которые можете. Это позволит вам в будущем получать более широкую картину о том, не пытается ли пользователь сломать вашу систему, получить выгоду или нанести ущерб вашей компании.

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

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

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

Это всё. Спасибо, что прочитали или прослушали мой доклад.