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