Если вам есть, что сказать сообществу профессионалов ИБ и ИТ – заведите здесь свой блог

«Антифрод из коробки» - это утопия

Аватар пользователя Rustem
Автор: Хайретдинов Рустэм, InfoWatch

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

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

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

Никакой особой rocket science в этом процессе нет. В крупных компаниях обычно существуют и хранилища логов, и аналитические системы и креляторы, реализованные например, в SIEM. Если большинство транзакций совершаются в одной бизнес-системе, например в АБС, то реализовать базовые anti-fraud функции без дополнительного программного обеспечения не составит труда. Тем не менее на рынке присутствуют десятки систем, специализирующиеся на противодействии мошенничеству и на них есть спрос.

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

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

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

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

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

В результате обе стороны недовольны – заказчик готов платить только за результат, для которого база правил «из коробки» явно недостаточна. Чтобы показать реальный результат, поставщик должен сделать полноценное (и, по ожиданиям, заказчика - бесплатное) внедрение. Без гарантий покупки ни один поставщик такое внедрение делать не готов. Но чаще всего такая коллизия решается в пользу покупки лицензий с правилами по умолчанию.

Вот и стоят в большинстве компаний системы с правилами «из коробки» - не адаптированными и поэтому не эффективными и раздражающими пользователей с обеих сторон ИТ-прилавка. Если для внутренних пользователей такие решения еще можно компенсировать оргмерами – например, заставлять операторов делать определенные операции так и только так, то для внешних пользователей такие правила не работают. Как часто летающий пользователь банковских карт я постоянно спрашиваю знакомых производителей и пользователей anti-fraud-решений, можно ли в их системе сделать правило, делающее легитимными две подряд через два часа транзакции по пластиковой карте в Москве и Киеве (самолет летит 1 час 45 минут), но нелегитимными в Москве и Лондоне (самолет летит 4 часа). Угадайте ответ.

Оцените материал:
Total votes: 317
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.