Как защищают банки: разбираем устройство и принципы банковского антифрода

Максим Федотенко, 21.04.2017
Системы антифрода, используемые в банковской сфере и стоящие на страже интересов кредитных учреждений и денег их клиентов, привлекают совершенно здоровый интерес как специалистов по информационной безопасности, так и блекхетов. Но вот незадача: все эти системы действуют по принципу black box, а создатели не торопятся раскрывать принципы их работы. Как всегда в таких случаях, журнал «Хакер» спешит на помощь!

Фрод становится возможен из-за недостаточной защищенности технологий и оконечных устройств пользователей, фишинга, социальной инженерии и подобного. Системы антифрода по атрибутам и признакам транзакций пытаются выявить фрод (мошеннические транзакции). Таких систем на рынке, в том числе и рынке России, достаточно много. Это, например, NICE Actimize, Eye4Fraud, SecureBuy Phoenix FM, RSA Adaptive Authentication, IRIS Analytics (IBM), Fraudwall и многие другие. Причем хорошие решения — дорогие решения. Вендоры получают за свои продукты огромные деньги, и совершенно понятно их нежелание раскрывать алгоритмы работы систем. Самые продвинутые решения используют алгоритмы машинного обучения.

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

Архитектура системы антифрода

В общем виде архитектура системы дистанционного банковского обслуживания (ДБО) выглядит следующим образом.

Архитектура ДБО

Обычно банк предоставляет пользователю несколько каналов управления банковским счетом удаленно. Наиболее распространен доступ через браузер или с использованием мобильных приложений. Пользователь выполняет действие в своем браузере или мобильном приложении, транзакция поставляется на Frontend-сервер, который уже отправляет ее на Backend-сервер ДБО и далее в АБС (автоматизированная банковская система / расчетная система) банка для проведения расчетов. Один из возможных вариантов встраивания системы антифрода в такую архитектуру систем ДБО показан ниже.

Система антифрода в архитектуре ДБО

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

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

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

В общем смысле любая система антифрода ДБО определяет возможность выполнения транзакции, которую инициировал пользователь ДБО. При этом система оценивает рискованность данной транзакции и в случае повышенного риска различными способами пытается дополнительно проверить, что транзакция легитимна. Способы могут быть автоматизированными (с точки зрения банка) или ручными. Например, можно отправить пользователю СМС или push-уведомление, чтобы он подтвердил транзакцию, попросить пользователя ответить на контрольные вопросы, перезвонить пользователю. Все эти действия призваны еще раз при помощи дополнительных факторов аутентифицировать транзакцию (в данной статье под аутентификацией транзакции/действия понимается подтверждение того, что действие совершил аутентифицированный пользователь). Наконец, после прохождения дополнительной многофакторной аутентификации система антифрода автоматизированно или аналитик вручную решает, возможно ли провести транзакцию.

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

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

Адаптивная аутентификация при входе в ДБО

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

Адаптивная аутентификация денежного перевода в ДБО

Соответственно, систему адаптивной аутентификации можно использовать не только для платежных систем, таких как ДБО, но и, например, для систем единой аутентификации, таких как Единая система идентификации и аутентификации.

Архитектура системы антифрода

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

Компонентная архитектура рассматриваемой системы антифрода

Второй компонент, BackOffice, с использованием нескольких веб-приложений управляет настройками Adaptive Authentication. У BackOffice собственная база данных.

Третий компонент, Case Management, отвечает за работу фрод-аналитика, в нем обрабатываются случаи, которые выпадают на ручной контроль. Принимаемое фрод-аналитиком решение передается обратно в Adaptive Authentication. Если необходима дополнительная аутентификация пользователя, в ход идут встроенные или внешние средства аутентификации.

Недавно в системе появился новый сервис — Trojan Protection. Он получает информацию об устройстве пользователя напрямую от браузера пользователя, а не через интернет-банк. Сервис анализирует полученную информацию и, обнаружив аномалии, заполняет свой черный список устройств. Затем этот список использует Adaptive Authentication при вынесении решения о легитимности события. Заметим, что получаемые Trojan Protection данные от браузера пользователя не синхронизируются с событиями в интернет-банке, а передаются гораздо чаще. В других частях мы еще коснемся работы этого сервиса более подробно.

WWW

Интересный анализ утечки материалов ЦРУ, опубликованных проектом Wikileaks: ЦРУ везде и всюду

Рисунок ниже показывает взаимодействие компонентов системы на уровне веб-сервисов. Все события от интернет-банка приходят на endpoint’ы Adaptive Authentication (AA Endpoint и Async AA Endpoint), которые обрабатывают синхронные и асинхронные вызовы соответственно. Endpoint компонента Adaptive Authentication Admin (AdminService Endpoint) используется интернет-банком или другим внешним сервисом для управления пользователями и сессиями. Такое управление проектируется в системе нечасто. В компоненте Case Management содержится Case Management Endpoint для управления кейсами фрод-аналитиком и других систем, например CRM организации.

Веб-сервисы RSA Adaptive Authentication

Как работает система антифрода

Теперь перейдем к внутреннему устройству системы антифрода и ее отдельным процессам. Начнем с обработки события.

Обработка события в системе антифрода

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

В антифрод-системе существует четыре ответа (рекомендованных действия): ALLOW (разрешить действие), DENY (запретить действие), CHALLENGE (произвести дополнительную аутентификацию) и REVIEW (разрешить действие, но при этом создать кейс в компоненте Case Management для последующей маркировки).

По ответам ALLOW и DENY никакого дополнительного процесса не предусматривается.

INFO

Наиболее безопасно использовать интернет-банк через мобильное приложение на платформе Apple iOS.

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

По ответу REVIEW также предусматривается дополнительный процесс. Но он связан с постобработкой. При REVIEW событие разрешается, но откладывается (создается кейс) в Case Management для дальнейшей обработки вручную фрод-аналитиком. Фрод-аналитик может промаркировать событие как «точно фрод», «возможно, фрод», «точно легально», «возможно, легально» и «затрудняюсь классифицировать». Данное решение затем передается в Adaptive Authentication и учитывается системой в модели для скоринга следующих событий. Иногда процесс по ответу REVIEW настраивают таким образом, что событие не будет разрешаться, а интернет-банк будет ждать, пока фрод-аналитик не вынесет своего решения (по сути, это некоторое перекрытие функциональности ответа CHALLENGE, где методом дополнительной аутентификации является решение фрод-аналитика).

Детализированный процесс обработки события в системе антифрода

Попробуем немного пояснить:

INFO

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

Заключение

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