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

Протокол взаимодействия

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

  • CREATEUSER. Этот метод применяется для создания нового пользователя в системе антифрода. Заводить пользователя в системе антифрода необязательно, но обычно это делают, если антифрод также будет аутентифицировать пользователя вместо интернет-банка или вместе с ним.
  • UPDATEUSER. Метод обновляет профиль пользователя, который был создан CREATEUSER, включая все сведения об учетных данных.
  • ANALYZE. Метод выполняет анализ рисков для одного или нескольких событий, при этом проводя аутентификацию пользователя. Это основной метод, с которого обычно начинается взаимодействие интернет-банка и антифрода в процессе анализа события.
  • AUTHENTICATE. Метод проверяет пользователя с помощью учетных данных.
  • CHALLENGE. Инициация дополнительной аутентификации пользователя.
  • QUERYAUTHSTATUS. Метод возвращает состояние аутентификации при асинхронном процессе дополнительной аутентификации пользователя.
  • NOTIFY. Этот метод позволяет интернет-банку оповестить антифрод об интересующих событиях, которые он может добавить в свои профили для использования в модели фрода.

Как видишь, все общение между интернет-банком и системой антифрода сводится к нескольким командам:

  • заведи или измени информацию о пользователях, например кодовое слово или телефон;
  • проанализируй событие и скажи вердикт;
  • аутентифицируй пользователя или произведи дополнительную аутентификацию;
  • сообщи, каков статус аутентификации, если она проводится в асинхронном режиме;
  • вот информация, которая, возможно, будет интересна, но ответ мне не нужен.

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

 

Разрешение операции (ALLOW)

Обычно большинство операций в интернет-банке проходят без каких-либо дополнительных действий с твоей стороны. Например, оплачивая услуги интернет-провайдера за текущий месяц, ты переводишь 500 рублей на счет провайдера. Этот платеж и есть для системы антифрода событие, вердикт по которому обычно положительный (ALLOW). Процесс обработки такой транзакции показан на рис. 1.

Рис. 1. Процесс обработки события в случае разрешения операции
Рис. 1. Процесс обработки события в случае разрешения операции

Пройдемся по этой схеме. Ты нажимаешь на кнопку денежного перевода (1), интернет-банк отображает тебе форму, в которой просит заполнить реквизиты операции, например название провайдера, номер лицевого счета и сумму (2). Ты их заполняешь и подтверждаешь отправку. При этом система антифрода при помощи JavaScript-скриптов собирает данные о твоем устройстве (об этом мы поговорим в следующих выпусках) (3), которые вместе с платежными данными отправляются в интернет-банк для собственно осуществления операции (4). После получения данных по операции пользователя интернет-банк просит антифрод их проанализировать и дать свое заключение. Для этого интернет-банк формирует запрос с методом ANALYZE к Adaptive Authentication. В этом запросе передаются данные о пользователе, об устройстве пользователя, идентификатор канала и собственно данные платежа — кому и сколько (5). Adaptive Authentication ищет устройство пользователя, рассчитывает уровень риска транзакции и применяет политики (6). В результате он вырабатывает рекомендованное действие, которое передается в ответе синхронного метода ANALYZE. В данном случае это разрешение (ALLOW). При этом ответ содержит идентификаторы сессии, пользователя, устройства, а также данные анализа — уровень риска, рекомендованное действие (ALLOW) и название сработавшего правила политики (7). Интернет-банк может установить идентификатор сессии в куку и передать его в клиентский браузер для идентификации браузера при следующем запросе (процесс не обязателен) (8). После этого интернет-банк проводит операцию, давая команду расчетной системе зачислить деньги на счет провайдера (9).

 

Рассмотрение операции (REVIEW)

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

Рис. 2. Процесс обработки события при передаче его на рассмотрение
Рис. 2. Процесс обработки события при передаче его на рассмотрение

Как и в предыдущем случае, вначале проходят типовые шаги (1–4). Далее интернет-банк отсылает запрос с методом ANALYZE на Adaptive Authentication (5), который обрабатывает транзакцию (6). В результате обработки Adaptive Authentication вырабатывает рекомендованное действие, которое передается в ответе метода ANALYZE (7). В данном случае — отправить на рассмотрение (REVIEW). При этом ответ содержит идентификаторы сессии, пользователя, устройства, а также информацию анализа — уровень риска, рекомендованное действие (в нашем случае REVIEW) и название сработавшего правила политики. Интернет-банк, так же как в предыдущем случае, может установить идентификатор устройства в куку и передать его в браузер клиента для идентификации экземпляра при следующем запросе (8). Основное отличие от процесса ALLOW состоит в том, что интернет-банк хоть и проводит транзакцию (9), но при этом в системе антифрода создается кейс в компоненте Case Management (10). В дальнейшем фрод-аналитик обрабатывает данный кейс, это ведет, например, к тому, что банк тебе перезвонит и задаст уточняющие вопросы об этой транзакции (11). При этом нужно понимать, что в данном процессе деньги на QIWI-кошелек уже будут переведены, а фрод-аналитик только лишь закроет кейс в Case Management (12), который передаст в Adaptive Authentication резолюцию по событию для корректировки модели фрода. А если на твоем компьютере или телефоне был вирус и он перевел деньги, нужно будет бежать в сторону QIWI и блокировать кошелек, пока деньги с него не обналичили...

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

 

Дополнительная аутентификация (CHALLENGE)

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

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

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

Получение данных сервером системы интернет-банка от программного обеспечения пользователя, передача данных в Adaptive Authentication и обработка им информации — стандартно для всех процессов (1–6). Но теперь Adaptive Authentication принимает решение о необходимости дополнительной аутентификации CHALLENGE (7). На рисунке также указаны группы данных, которые передаются в методах взаимодействия. Ты можешь сам изучить их, здесь мы остановимся только на специфичных данных. В этом случае антифрод говорит, какими дополнительными методами может быть аутентифицирован пользователь или транзакция.

После того как интернет-банк получил от антифрода информацию о необходимости дополнительной аутентификации, он отправляет в Adaptive Authentication запрос с методом CHALLENGE и выбранным методом аутентификации (8). В ответ Adaptive Authentication передает дополнительную информацию по данному методу (например, номер телефона или набор контрольных вопросов) (9). Интернет-банк предлагает пользователю пройти дополнительную аутентификацию (10), при этом отсылая пользователя на страницу системы антифрода в случае, например, контрольных вопросов (11a) или самостоятельно показывая их пользователю на собственной странице (11b). Пользователь вводит аутентифицирующую его информацию (12) и передает ее в интернет-банк (13). Интернет-банк вызывает метод AUTHENTICATE, содержащий информацию, переданную пользователем во время аутентификации (14). Adaptive Authentication аутентифицирует пользователя (15) и отвечает интернет-банку, успешно или нет аутентифицирован пользователь (16). Интернет-банк выполняет или запрещает транзакцию пользователя в зависимости от результата аутентификации (18).

INFO

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

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

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

В этом случае до (9) процесс выглядит так же, как при обработке синхронными методами. Но для аутентификации обычно используются внешние сервисы или Adaptive Authentication, с которыми пользователь взаимодействует напрямую. Интернет-банк переводит пользователя на процесс аутентификации (10), и внешний сервис аутентификации (который в общем случае может быть и самим Adaptive Authentication) запрашивает у пользователя, например, отпечаток пальца (если выбрана биометрическая аутентификация) (11–14). После этого ответственность за аутентификацию пользователя полностью несет внешний сервис, а интернет-банк должен постоянно запрашивать Adaptive Authentication о результате аутентификации пользователя при помощи метода QUERYAUTHSTATUS (15–19). Результат может быть как положительный или отрицательный, так и говорящий о том, что аутентификация еще не пройдена. Далее в зависимости от результата транзакция выполняется или нет (21).

 

Методы дополнительной аутентификации

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

 

Использование знаний пользователя

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

 

Использование в качестве фактора аутентификации мобильного устройства

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

Один из вариантов передачи одноразового пароля — отправка СМС (Out-of-Band SMS Authentication). Этот метод также работает через внешний сервис, но чаще используется в синхронном режиме. Он часто применяется банками, и ты можешь встретиться с ним, когда для подтверждения перевода приходит одноразовый пароль в СМС. Подробно процесс аутентификации методом Out-of-Band SMS Authentication изображен на рис. 5.

Рис. 5. Процесс дополнительной аутентификации методом отправки СМС
Рис. 5. Процесс дополнительной аутентификации методом отправки СМС

Например, ты выполняешь перевод теперь уже на Яндекс-кошелек (1, 2). Интернет-банк обращается с запросом ANALYZE к антифроду (3), который сообщает, что необходимо произвести дополнительную аутентификацию транзакции (4). После этого интернет-банк при помощи метода CHALLENGE сообщает системе антифрода о выборе Out-of-Band SMS Authentication (5), получает в ответ сообщение о необходимости запроса одноразового пароля и выводит тебе в браузере диалоговое окно с запросом одноразового пароля (6). Тем временем антифрод отправляет атрибуты транзакции и одноразовый пароль оператору связи (7), который уже пересылает их в СМС на твой телефон (8). Надеюсь, что ты читаешь всю эсэмэску и сверяешь, соответствуют ли присланные в сообщении атрибуты платежа тем, которые ты заполнял в браузере (9). Если они совпадают, то ты вводишь одноразовый пароль в диалоговое окно интернет-банка (10). Интернет-банк передает его из твоего браузера в банк (11, 12) и запрашивает методом AUTHENTICATE у системы антифрода, верно ли ты ввел одноразовый пароль (13). Антифрод проверяет совпадение с привязкой к операции и пользователю и отвечает на метод AUTHENTICATE, сообщая интернет-банку, успешно или нет прошла аутентификация. Если успешно, то деньги переводятся на кошелек.

INFO

На самом деле использование СМС для передачи одноразовых паролей нельзя считать достаточно защищенным. Содержание сообщения может быть перехвачено еще до того, как оно дойдет до легитимного пользователя (см. «Взлом мобильной связи через SS7: перехват SMS, слежка и прочее»), а следовательно, хакер нивелирует второй фактор аутентификации. Порог вхождения в реализацию такой атаки с каждым годом становится все ниже...

 

Использование в качестве фактора аутентификации мобильного приложения

Дополнительная аутентификация может быть также реализована с помощью мобильного приложения и push-нотификации (One-Time Password Pushed to Mobile App Authentication). В случае рассматриваемой системы это всегда внешний сервис, при этом взаимодействие может быть как в синхронном, так и в асинхронном режиме. Система антифрода в этом случае отсылает одноразовый пароль не в СМС, а в push-нотификации на зарегистрированное на тебя мобильное приложение банка. Ты должен также ввести полученный одноразовый пароль в интернет-банке. Для встраивания возможности получения push-уведомлений в мобильное приложение можно воспользоваться мобильным SDK (набором библиотек, который предлагает производитель системы антифрода, для выполнения функций аутентификации и сбора данных для анализа риска).

Следующим рассмотрим подтверждение на мобильном устройстве при помощи биометрических датчиков (Out-of-Band Biometrics Authentication). Этот метод использует внешний сервис и обычно асинхронный режим. Для проведения биометрической аутентификации в настоящий момент рассматриваемая нами система антифрода имеет возможность использовать отпечаток пальца (Fingerprint) и сетчатку глаза (Eyeprint). Эта функциональность может быть реализована библиотеками, идущими в комплекте с мобильным SDK системы антифрода. Вариация такого процесса приведена на рис. 6. Некоторые банки передают реквизиты перевода на привязанное к тебе в системе интернет-банка мобильное устройство при помощи push-нотификации. При этом на экране твоего мобильного устройства выводится окно с атрибутами и запрашивается подтверждение при помощи, например, отпечатка пальца. Результат подтверждения отправляется мобильным приложением в систему антифрода.

Рис. 6. Процесс дополнительной аутентификации при помощи отпечатка пальца
Рис. 6. Процесс дополнительной аутентификации при помощи отпечатка пальца

Подробнее процесс выглядит следующим образом. Ты оплачиваешь покупку через интернет-банк (1, 2). Интернет-банк запрашивает решение у системы антифрода методом ANALYZE и получает ответ с Challenge (3, 4). Интернет-банк выбирает описанный нами способ аутентификации транзакции и отсылает в систему антифрода запрос CHALLENGE (5), после чего получает ответ со статусом ожидания (6). При этом антифрод отсылает атрибуты транзакции при помощи серверов push-нотификации на твое зарегистрированное мобильное приложение (7, 8), где ты проверяешь, сколько и кому ты хочешь заплатить, и подтверждаешь платеж отпечатком пальца (9). Если ты подтвердил платеж, то результат этого передается в систему антифрода при помощи облачных сервисов (10, 11). Тем временем интернет-банк периодически опрашивает систему антифрода методом QUERYAUTHSTATUS о результате аутентификации (12) и, как только его получает (13), пропускает или нет транзакцию в зависимости от этого результата.

INFO

Альянс FIDO стандартизирует методики безопасной аутентификации. Архитектура FIDO предполагает, что биометрические шаблоны (биометрические характеристики зарегистрированной личности, которые сохраняются в системе для дальнейшего сравнения с биометрическим образцом) хранятся на устройстве пользователя и никогда его не покидают. При этом, например, производители мобильных устройств сохраняют их в специально защищенных областях: Apple использует Secure Enclave, Android с версии 6.0 — шифрование при помощи Trusted Execution Environment (TEE) (см. «Сканер отпечатка пальца: безопасность и обход защиты»). Однако сторонний софт, установленный на твой мобильный телефон, как раз наоборот — чаще передает твои биометрические данные на сервер для хранения и проведения операций сравнения. И завтра изображение сетчатки твоего глаза будет продаваться на подпольных форумах, а ее, как пароль, не заменишь...

В рассматриваемой нами системе используется еще такой метод, как подтверждение на мобильном устройстве с подписью операции (Online Transaction Signing Authentication). Он похож на предыдущий, однако после подтверждения тобой платежа в мобильном приложении ответ еще и подписывается электронной подписью для защиты от модификации. Антифрод осуществляет проверку подписи и аутентифицирует операцию.

Также иногда предлагается использовать подтверждение на мобильном устройстве с подписью операции через интернет-банк (Online Transaction Signing Authentication via Bank). Вкратце этот процесс выглядит следующим образом (см. рис. 7).

Рис. 7. Процесс дополнительной аутентификации методом подписи транзакции при помощи отпечатка пальца с передачей через банк
Рис. 7. Процесс дополнительной аутентификации методом подписи транзакции при помощи отпечатка пальца с передачей через банк

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

INFO

Еще одна проблема биометрической аутентификации — это возможность подмены. Необязательно, что твои отпечатки пальцев продадут на андеграундных форумах, их можно скопировать удаленно. Например, вспомним, как Starbug (Ян Крисслер) восстановил отпечаток пальца министра обороны Германии по фотографиям. А системы распознавания лиц можно обмануть при помощи систем виртуальной реальности (см. «Для обхода биометрической аутентификации нужно VR-устройство и фотографии с Facebook»), причем даже новые датчики Samsung Galaxy S8 обходятся еще легче — при помощи нескольких фотографий (см. «Систему распознавания лиц Samsung Galaxy S8 обманули при помощи фото»).

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

 

Использование в качестве фактора аутентификации почтового ящика

Еще одним способом дополнительной аутентификации может быть отправка почтового сообщения (Out-of-Band Email Authentication). Метод по сути аналогичен звонку на телефон, но используется другой канал доставки одноразового пароля (или ссылки) — электронная почта.

Таковы основные возможности системы антифрода по дополнительной аутентификации и процессы аутентификации, предусмотренные ей.

 

Запрет операции (DENY)

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

Рис. 8. Процесс обработки события в случае запрета операции
Рис. 8. Процесс обработки события в случае запрета операции
 

Заключение

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

WWW

Не забудь прочесть первый материал из этого цикла: «Как защищают банки: разбираем устройство и принципы банковского антифрода»

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии