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

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

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: опции, которые используются редко

Кейс

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

Решение

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

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

Результат

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

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

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

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

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

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

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

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

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