Слагаемые защиты ДБО

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

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

Социальная инженерия – опасное оружие в руках злоумышленников

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

Есть простой пример синтетического теста в одной из ИТ-компаний. В дождливую и ветреную погоду на адрес корпоративной почтовой рассылки направляется письмо с архивом и следующим текстом: "На машину во дворе упало дерево. Просьба владельца подойти к машине". Результат теста: 83% открыли архив, из них 35% действительно приехали в офис на своем авто, а у 15% машина была запаркована на подземном паркинге.

О чем нам говорит этот пример? Ключевая проблема – это ненадежность пароля или незащищенность канала передачи OTP (хотя эти аспекты и являются значимыми). Задача поважнее – внедрение методик защиты от мошенничества, которые были бы стойкими к социальной инженерии. Доля использования социальной инженерии со стороны злоумышленников в схемах атак на клиентов лишь растет. И, с одной стороны, это свидетельствует о повышении защищенности технических аспектов банковских сервисов, а с другой – показывает простоту и уязвимость именно клиентской стороны. И если вчера "социалка" использовалась исключительно для получения части данных клиента, а атака проводилась в режиме "без клиентов", и сам пользователь не способствовал совершению неправомерной операции, то сегодня фраз от клиентов "А что же я наделал" становится все больше. Социальная инженерия в современном мире – это не только возможность провести одну нелегитимную операцию, но и способ получить полный доступ к счету или платежному инструменту, который сводит на нет многие технические аспекты защиты от злоумышленников.

Вина ли это только клиента? Конечно, нет. Правда, отчасти… Добрая половина таких случаев – это уязвимость бизнес-процессов банка, риски для которого не были просчитаны в достаточном объеме.

Можно ли предупредить мошенничество?

С большой долей вероятности можно ответить "да".

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

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

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

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

Приведем пример. Выполняется стандартная операция по привязке новой банковской карты к счету клиента. При этом в системе банка фиксируется несколько просмотров карточки клиента, остатков и истории операций по карте со стороны операциониста или сотрудника call-центра. В таком случае выдача карты становится уже подозрительным событием. Другими словами, в процессе выпуска карты событие "просмотр остатков" влияет на уровень риска конечной операции.

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

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

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

***

За время подготовки данной статьи ЦБ РФ выпустил "Обзор финансовой стабильности", в котором была озвучена проблема безопасности интернет-, мобильного и прочих видов дистанционного банкинга. Начиная с 2017 г., качество платежных сервисов будет проверяться госрегуляторами с точки зрения защищенности от киберугроз. ЦБ РФ также планирует вводить сертификацию дистанционных сервисов "на соответствие требованиям информационной безопасности". Сейчас каждый банк самостоятельно обеспечивает безопасность клиентских операций на том уровне, который может обеспечить. И, к сожалению, этого недостаточно. По статистике ЦБ, только в январе–сентябре 2016 г. хакеры пытались совершить с помощью платежных сервисов 102,7 тыс. несанкционированных операций со счетами физлиц, тогда как за аналогичный период 2015 г. таких попыток было зафиксировано всего 16 тыс. При этом ущерб частным клиентам от действий мошенников за три квартала этого года составил около 1,25 млрд руб.

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