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

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

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

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

WWW

Сотрудники МВД России и ФСБ России задержали интернет-хакеров

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

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

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

Обычно банк предоставляет пользователю несколько каналов управления банковским счетом удаленно. Наиболее распространен доступ через браузер или с использованием мобильных приложений. Пользователь выполняет действие в своем браузере или мобильном приложении, транзакция поставляется на 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, где методом дополнительной аутентификации является решение фрод-аналитика).

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

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

  • (1, 2) Пользователь в интернет-банке инициирует событие (например, заполняет и отправляет платежное поручение).
  • (3) Клиентская часть (если это браузер, то при помощи JavaScript) собирает некоторые данные об устройстве пользователя, его программном обеспечении, браузере, скриптах и прочем и (4) вместе с данными по платежному поручению отправляет в банк.
  • (5) Все эти данные переводятся серверной частью интернет-банка в стандартную структуру для Adaptive Authentication и отправляются в него.
  • (6) Adaptive Authentication производит поиск пользователя интернет-банка. Если такой пользователь отсутствует, то (6a) заводит его у себя.
  • (7b, 7c) При этом Adaptive Authentication может запросить дополнительные данные о пользователе (у системы интернет-банка или у самого пользователя).
  • (7d, 7e) Пользователь заполняет форму (например, адрес, мобильный телефон) и передает данные о себе в Adaptive Authentication.
  • (7f) Adaptive Authentication обновляет информацию о пользователе в своей базе данных.

INFO

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

  • (8) Далее Adaptive Authentication обрабатывает событие: рассчитывает риск и обрабатывает по правилам политики. В результате чего он формирует рекомендованное действие (см. выше) — ALLOW, DENY, CHALLENGE или REVIEW.
  • (9) Рекомендованное действие передается в интернет-банк. В случае CHALLENGE передаются еще и доступные методы дополнительной аутентификации.
  • (10a) Если в систему интернет-банка было возвращено рекомендованное действие CHALLENGE, то интернет-банк (если согласен с рекомендованным действием) запрашивает Adaptive Authentication произвести аутентификацию и передает выбранный им метод дополнительной аутентификации.
  • (10b) Adaptive Authentication сам запрашивает пользователя провести дополнительную аутентификацию или использует для этой цели внешний сервис, в том числе это может быть собственно интернет-банк.
  • (10c, 10d) Сервис проводит аутентификацию и (10e) возвращает результат в Adaptive Authentication.
  • (10f) Adaptive Authentication передает в интернет-банк статус дополнительной аутентификации пользователя.
  • (11) После получения рекомендованного действия и, при необходимости, статуса дополнительной аутентификации интернет-банк проводит операцию пользователя или запрещает ее в зависимости от того, что сообщила система антифрода.
  • (12a) В случае рекомендованного действия REVIEW система антифрода создает также кейс в компоненте Case Management.
  • (12b) Данный кейс обрабатывается вручную фрод-аналитиком, который принимает решение и маркирует событие.
  • (12c) Решение фрод-аналитика передается из компонента Case Management системы антифрода в Adaptive Authentication для учета в модели и обработке следующих транзакций.

Заключение

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