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

Как автоматизировать контроль прав линейных сотрудников банка? Что лежит в основе моделей выявления аномального поведения? От чего зависит безопасность банковских бизнес-операций?

Главная>Информационная безопасность>О банковском мошенничестве в целом и многообразии внутреннего в частности
Информационная безопасность Тема номера

О банковском мошенничестве в целом и многообразии внутреннего в частности

Дата публикации:
16.09.2022
Посетителей:
796
Просмотров:
810
Время просмотра:
2.3

Авторы

Автор
Алексей Сизов Руководитель направления противодействия мошенничеству центра прикладных систем безопасности компании «Инфосистемы Джет»

 

Как автоматизировать контроль прав линейных сотрудников банка?


Что лежит в основе моделей выявления аномального поведения?


От чего зависит безопасность банковских бизнес-операций

 

 

По данным МВД, за последние 10 лет количество противоправных действий в сфере высоких технологий возросло почти в 250 раз — с 2800 в 2012 году до почти 700 000 в 2021-м. И это лишь те случаи, когда бизнес обращался в правоохранительные органы. Реальных кейсов как минимум в три раза больше.

 

Если взять финансовую сферу и посмотреть статистику ФинЦЕРТ ЦБ, мы увидим, что объем банковских операций, совершенных без согласия клиентов, в 2021 году достиг 13,5 млрд руб. Параллельно с увеличением числа угроз растут и потребности банков в инструментах для противодействия злоумышленникам. Тема защиты каналов ДБО (интернет-банкинг, e-commerce, классические операции по картам и др.) уже исхожена вдоль и поперек. Гораздо меньше внимания уделяется мошенничеству, активную роль в котором играют сотрудники банков. И очень зря.

Сотрудники банка могут совершать хищения двух видов:

 

  • Финансовые (деньги со счетов)

  • Информационные (сведения о клиентах, их счетах, доступных продуктах и услугах)

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

Глава 1. Контроль привилегий


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


Представьте: из 1000 сотрудников банка двое действительно хотят что-то украсть, но инструменты для этого вы по умолчанию выдаете всем. При определенных обстоятельствах украдут уже не двое, а как минимум десять: просто потому что поймут, что у них есть такая возможность. Чтобы нивелировать риск, нужно снизить число людей с избыточными правами.

Когда банк хочет контролировать права сотрудников, то сталкивается с базовым набором проблем:

 

  1. Права не приведены к единому формату. Даже если у заказчика все в AD или есть IdM, он получает тысячи строк, не приближающих, а отдаляющих его от решения задачи.
  2. На одну и ту же бизнес-операцию может существовать несколько, а иногда и 10+ разрешений. Дело в том, что эти операции могут одновременно инициироваться в разных учетных системах. К примеру, call-центр работает в CRM, операционисты — в АБС, VIP-менеджеры — на отдельных АРМ и т. д. Я не встречал заказчиков, у которых изначально был реализован бизнес-функциональный подход к выделению прав доступа (чтобы они регистрировались исходя не из функции учетной системы, а из бизнес-функции работы с клиентом).
  3. Зачастую не решен вопрос segregation of duty — определения конфликта полномочий в ролях.
  4. Не налажены процессы получения и отзыва разрешений на операции.
  5. Не ведется контроль использования разрешений (начиная с одного сотрудника и заканчивая целым подразделением).
  6. Не ведется контроль соответствия бизнес-процессов установленным требованиям.

 

Кроме того, зачастую никто банально не знает, сколько вариантов одного процесса существует в банке (пример — кейс в банке № 2, описанный ниже).


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

В среднем линейный сотрудник постоянно использует всего 40% выданных ему прав. Логично было бы утилизировать лишние, но такая практика, к сожалению, встречается редко. У нас были кейсы, когда подразделения отзывали всего 15% избыточных привилегий. Это очевидный риск.

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

 

  • появления или исчезновения операций по разрешениям;
  • аномального роста количества операций по группам;
  • ситуационного использования разрешения (один кейс за долгосрочный период).


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

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

Итак, мы разобрались с правами доступа и утилизировали лишние. Число сотрудников, которые могут совершить противоправные действия «просто потому что могут» существенно уменьшилось. Теперь целимся в настоящих внутренних мошенников. Они понимают, где их контролируют и на чем могут поймать, поэтому действуют хитрее. Здесь потребуются более сложные аналитические инструменты. Мы используем для выявления и пресечения внутреннего мошенничества платформу Jet Detective.

Что делает Jet Detective


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

Выявление аномального поведения: кейс в банке № 1


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


Простой пример — операция по закрытию депозита с изъятием средств. В данном случае довольно сложно отличить мошенничество от легитимных действий клиента. Тщательно мониторить все подобные операции невозможно — банально не хватит ресурсов. Здесь на помощь приходят автоматизированные ИБ-системы. В Jet Detective наряду с 50+ стратегиями оценки конкретных схем внутреннего мошенничества есть инструменты профилирования, ориентированные именно на выявление и контроль аномального поведения сотрудников.

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

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


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

Пример работы Jet Detective: анализ аномального поведения сотрудника в рамках кластера опций


Группировка опций

Для каждого сотрудника проводится анализ используемых опций за заданный период. Они делятся на три кластера:

Кластер 1: опции, используемые практически каждый день

Кластер 2: периодически используемые опции

Кластер 3: опции, которые используются редко

Кейс

Резкое увеличение доли транзакций в рамках кластера относительно среднего исторического показателя


Решение

Для выявления аномального поведения сотрудника для каждой тройки «сотрудник-день-кластер» система вычисляет следующую характеристику:

где pu, d, cl — процент опций из кластера (cl), использованных сотрудником (u) в день (d), mean(pu, d,cl) — вычисляется среднее значение характеристики pu, d, cl по всем дням. Характеристика описывает отклонение доли транзакций внутри кластера относительно среднего показателя.
Анализируем поведение сотрудника Ивана Петрова (ZUMJ). Первый график показывает, сколько раз он воспользовался опциями из 3-го кластера. Второй график — изменение характеристики p_chu, d, cl для 3-го кластера.

Рис. 2. Использование сотрудником опций из 3-го кластера
Рис. 3. Изменение характеристики p_chu, d, cl для 3-го кластера

 

Результат

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

Контроль бизнес-процессов: кейс в банке № 2


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

 

  • Описать все бизнес-процессы, поддерживать описание в актуальном состоянии и контролировать исполнение каждого из них потоковой системой транзакционного анализа. Это сработает, но есть нюанс. Описание и актуализация процессов в нашем динамично меняющемся мире (модернизация систем, появление новых продуктов и услуг и т. д.) могут превратиться в бесконечный ремонт в квартире. Его можно начать, но сложно закончить, если делать все своими силами.
  • Автоматизировать контроль процессов с помощью систем логирования бизнес-операций и «умных алгоритмов». Jet Detective позволяет определить, как выглядит процесс сейчас, насколько он безопасен, и настроить механизмы контроля. Это достаточно сложная технология, которая практически не встречается на рынке.


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


Шаг 1. Разработанный алгоритм анализирует историю действий всех сотрудников за Х месяцев по ключевому событию «выдача карты». Система определяет все варианты операций на этапах оформления, изготовления, выдачи и активации карты, которые выполняли люди из разных отделений, подразделений и в разном ПО.


Далее система создает логические связи и формирует для события «выдача карты» варианты цепочек действий: «заявление на выпуск», «фиксация карточного продукта», «установка параметров карты» и т. д.


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


Шаг 3. Система контролирует отклонение исполняемого бизнес-процесса (т. е. каждого «выпуска карты») от эталона и оповещает специалистов банка о подозрительных кейсах.

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

 

Рис. 4. Пример визуализации связей в виде графа

Уведомления об обновлении тем – в вашей почте

Информационная безопасность - обзор основных положений. Часть 1

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

Информационная безопасность в России: опыт составления карты

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

Интервью Алексея Комкова, Технического директора компании "Лаборатория Касперского"

Интервью Комкова Алексея, технического директора компании "Лаборатория Касперского" информационному бюллетеню "Jet ...

InfoSecurity Russia 2016: мнения участников

InfoSecurity Russia 2016 завершилась на днях в Москве, мы попросили поделиться своими впечатлениями ее участников

Open Source в SOC

Тест-драйв Elastic Stack. Что показало тестирование? Плюсы и минусы ПО с открытым кодом.

The Standoff: топ-10 самых ярких ИБ-фактов

С 12 по 17 ноября компания Positive Technologies провела киберполигон The Standoff — мероприятие, где на виртуальной платформе проводили киберучения и стримы с ИБ-экспертами со всего мира.

Защита от несанкционированного доступа к информации

Настоящий Руководящий документ (РД) устанавливает классификацию программного обеспечения (ПО) (как отечественного, так и импортного производства) средств защиты информации (СЗИ), в том числе и встроенных в общесистемное и прикладное ПО, по ...

Информационная безопасность в Интранет: концепции и решения

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

Облачная НЕбезопасность и как с ней бороться

Риски частных, публичных инфраструктурных облаков и облачных приложений. Как защитить компанию при переходе в cloud-среду?

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня