Новости

Как защитить интернет-банкинг

Как защитить интернет-банкинг

20.09.2010

Андрей Тархов

Руководитель отдела внедрения и техподдержки


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

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

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

Защита динамическими методами

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

К динамическим методам можно отнести одноразовые пароли (OTP, one-time password) и методы, работающие в режиме запрос-ответ (challenge-response). К первым относятся: пароли по SMS, таблица паролей, аппаратные генераторы одноразовых паролей, программные генераторы одноразовых паролей.

Пароли по SMS и таблица паролей — наиболее распространенные методы на сегодняшний момент, так как просты в реализации и относительно дешевы, однако обладают рядом недостатков. Так, например, SMS отправляются по открытым каналам связи, а значит подвержены перехвату, к этому методу так же применима атака «дублирования SIM-карты».

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

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

Алгоритмы генерации паролей

Аппаратные генераторы одноразовых паролей, в отличие от скретч-карт имеют значительно больший период использования (до 8 лет) и кроме того, могут быть защищены PIN-кодом (проверяемым самим устройством), что образует дополнительный уровень защиты.

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

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

Алгоритмы, работающие только «по времени», используют дискретное значение текущего времени как входной аргумент. Это позволяет ввести такой важный параметр как «время жизни» одноразового пароля. Но такие алгоритмы имеют недостаток в виде «времени простоя» — промежутка равного длительности дискрета времени в течение которого генератор просто не может выдать новое значение, так как аргумент, на основе которого происходит расчет, не меняется.

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

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

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

Усиление системы аутентификации может быть выполнено с использованием методов, реализующие систему «запрос-ответ». Простейший вариант сводится к следующему: сервер генерирует запрос, пользователь вводит его в устройство, которое выдает ответ. Ответ формируется по алгоритму с использованием общего секрета, известного серверу и пользователю (устройству). Простейший и наиболее распространенный вариант — алгоритм HMAC , как одна из реализаций MAC (message authentication code)

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

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

К аппаратным генераторам можно отнести и чипованные банковские EMV-карты, реализующие технологию CAP (chip authentication program, MasterCard) или DPA (Dynamic Passcode Authentification, Visa). С помощью простого в использовании устройства, не подключаемого к компьютеру, можно сгенерировать одноразовый пароль для аутентификации пользователя (алгоритмы основаны только на счетчике событий). Стоит отметить, что системы EMV-аутентификации взаимодействуют с процессингом, поэтому они должны быть сертифицированы самой платежной системой MasterCard или EMV.

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

Авторизация транзакций

Авторизация или подпись транзакций в подавляющем большинстве случаев полностью повторяет процесс аутентификации — необходим ввод одноразового пароля, получаемого одним из методов (понятно, что каждая транзакция «съедает» очередное значение из таблицы паролей). Как говорилось выше, это не защищает от двух типов атак, при реализации которых пользователь подтвердит «правильным» одноразовым паролем транзакцию, параметры которой будут изменены прокси-элементом. Причина в том, что значение, авторизующее транзакцию (одноразовый пароль), не связано с параметрами этого процесса. То есть происходит подтверждение не правильности транзакции, а просто факта ее проведения.

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

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

Подпись транзакций с использованием PKI, то есть формирование электронно-цифровой подписи в классическом понимании этого слова — наиболее надежное решение с точки зрения используемых алгоритмов. Опасность здесь заключается в том, что в большинстве случаев пользователь не контролирует, какие и сколько именно данных подписываются. . В ходе проведения целевых атак происходит инфицирование пользовательских компонентов системы, в результате чего прокси-элемент, во-первых, может менять параметры транзакций, а во-вторых, выполнять дополнительные транзакции. В ряде случае риски угроз второго типа можно минимизировать за счет полного отключения кеширования PIN-кода. Однако в этом случае каждая операция с ключевым материалом будет требовать ввода PIN-кода, иногда несколько раз за одну операцию (зависит от реализации носителя и системы). Это в свою очередь внесет путаницу: вроде как транзакция одна, а PIN запрашивается дважды…. или все же прошло две транзакции? В любом случае, уверенности в том, что подписываются правильные параметры нет. Такой метод востребован и применим в корпоративной среде по двум причинам. Во-первых, необходимо соблюсти юридическую значимость подписи, что накладывает жесткие требования на используемые методы и алгоритмы (что не требуется при работе с физическими лицами). Во-вторых, существует штат высококвалифицированных администраторов, призванных решать все возникающие вопросы.

Наиболее «контролируемым» вариантом является подпись транзакции не на базе «слепка», а с использованием самих параметров транзакции. В этом случае в устройство вводятся параметры транзакции, и на их основе генерируется «подпись». Этот метод гарантирует прямую зависимость подписи от параметров, чего нельзя добиться в случае подписи «слепка» (будет однозначная зависимость между слепком и подписью, но не подписью и параметрами). Понятно, что метод прямой подписи более сложен с точки зрения самого пользователя: так как в устройство нужно «вколотить» несколько значений. Кроме того, необходимо определить количество подписываемых параметров и выбрать устройство, удовлетворяющее этим требованиям. В качестве подписывающего устройства так же могут использоваться EMV-карты — пользователь вставляет карту в миниатюрное устройство, вводит PIN, а затем параметры транзакции. На их основе карта рассчитывает значение, играющее роль подписи.

Предпочтение метода

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

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

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

Менее очевидным являются концептуальные аспекты используемых методов: насколько надежен данный метод вообще. Необходимо быть готовым к тому, что в какой-то момент времени возникнет необходимость заменить один из используемых методов по причине его ненадежности и хорошо, если эта необходимость начнет возникать постепенно, предусматривая таким образом время, чтобы перестроить систему (например, переход со стандартной длины ключа 1024 в RSA на 2048 обсуждается уже несколько лет). Если же в один прекрасный момент будет обнаружена уязвимость алгоритма, на котором основан используемый метод, то это будет срочная задача. В связи с этим возникает вопрос о необходимости расширения перечня (или замене) методов аутентификации без изменения архитектуры бизнес-системы. Сюда же можно добавить возникновение новых методов, которые более надежны и удобны — технологии атак всегда идут с опережением: постоянно появляются новые приемы и находятся новые опасности и здесь рассматриваются не только технические аспекты, но и психологические, и социальные.

Еще один вопрос, который необходимо рассмотреть: способ взаимодействия с клиентами. Сформировался устойчивый термин — канал, описывающий, каким образом пользователь взаимодействует с системой: Интернет, мобильный интернет, телефон, офис. Каждый канал имеет свою специфику и требует собственную систему подтверждения личности — аутентификации, наиболее подходящую для данного кагала в том числе и с точки зрения применимости (например, для IVR-канала абсолютно не подходят usb-токены, как и все другие контактные методы).

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

Отдельным пунктом можно выделить функционал управления жизненным циклом аутентификаторов. Вполне понятно, что каждый из них проходит определенные этапы: Генерация (для скретч-карты), загрузка конфигурационного файла (для генераторов); Регистрация не пользователя; Блокировка; Разблокировка; Приостановка; Управление PIN (задание, смена, разблокировка); «Отвязка» от пользователя; Замена.

Задача управления усложняется при подключении новых или сторонних методов аутентификации или устройств, так как это требует сопряжения «родных состояний» аутентификаторов (загружен в систему, зарегистрирован, заблокирован и т.д.) с теми, которые предусмотрены подсистемой управления платформы аутентификации.

Критерии выбора платформы

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

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

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

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

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

Как говорилось выше, кроме критерия «аутентификация пройдена или не пройдена» существуют и другие, позволяющие принять решение о легитимности транзакции.

Представьте ситуацию, когда один и тот же клиент выполняет две транзакции с интервалом в две минуты из двух точек, расстояние между которыми несколько тысяч километров, или наоборот — с одного IP-адреса выполняются транзакции трех разных клиентов практически одновременно. Анализ параметров транзакции позволят принять решение о риске мошенничества.

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

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

Оценка эффективности защиты

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

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

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

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

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

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

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

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

Возврат к списку

 

Защита банкоматов

Имя* Компания* Email* Телефон

* - Поля, обязательные для заполнения

Компрометация приложений для смартфонов

Имя* Компания* Email* Телефон

* - Поля, обязательные для заполнения

Семинар ATAR

Фамилия* Имя* Должность* Компания* Email* Телефон* Защита от автоматического заполнения Введите символы с картинки*

* - Поля, обязательные для заполнения

Заполните поля

Защита от автоматических сообщений
CAPTCHA
Введите слово на картинке*

Заполните поля

Защита от автоматических сообщений
CAPTCHA
Введите слово на картинке*