Intelligent Enterprise: Когда проблема мошенничества в системах ДБО стала особенно актуальной?
Василий Окулесский: Возникла она в 2009 году и касалась тогда преимущественно физических лиц. Именно в то время в интернет-банке начали воровать ключи электронной подписи пользователей. Уходившие суммы были сравнительно небольшими, но значительное количество происшествий подвигло нас заняться проблемой вплотную. Чуть позже инциденты в системах ДБО стали происходить и с юридическими лицами. Число происшествий постоянно росло и к 2011-му достигло критических значений, что вылилось в очень серьезные потери банка и клиентов. Так что откладывать решение этой проблемы было уже нельзя.
Как вы выбирали решение? Насколько предложения рынка отвечали вашим ожиданиям?
Сначала был проведен мозговой штурм: мы выясняли, какие дырки в системе ДБО нужно закрыть и как это сделать. Потом проанализировали продукты, предлагаемые на рынке, и поняли, что они не вполне соответствуют нашим ожиданиям. Был выбран компромиссный вариант: берем зарубежное промышленное решение и добавляем в него свои наработки.
Дело в том, что необходимых российских решений в тот момент не нашлось, а зарубежные оказались основанными на иных реалиях и иной ментальности. Западный пользователь чаще всего законопослушен, и ему предоставляется большая свобода в выборе технологий подтверждения платежей, авторизации. У нас же всё построено жестче, нет такого облегченного доступа и соответствующих нарушений. А значит, если воспользоваться готовой импортной системой, то она на 60% будет молотить пустое пространство. Кроме того, западные решения требуют определенного качества клиентских каналов и технических средств. На наших каналах эти продукты работают не так хорошо, как хотелось бы, а потому необходима адаптация и интерфейса, и протокола взаимодействия, и правил.
В результате мы пришли к выводу: нужно отдать предпочтение системам, заточенным под онлайн, но с меньшим числом зафиксированных правил, чем за рубежом, и с возможностью добавлять некоторое количество наших правил. После долгого отбора из десятка импортных решений выделили два продукта израильского производства, основанных на одной идеологии. В ее рамках формируется профиль клиента, который можно создавать по индивидуальным признакам, относящимся как к каналам связи, так и к месту нахождения клиента (особенно к его рабочему месту), к его поведенческим особенностям, специфике проведения платежей, их периодичности и пр. Другими словами, используются какие-то характеристики, которые можно измерить и сделать основой определенной модели.
Мы оценивали все характеристики профиля клиента в соответствии с его текущим состоянием и конкретным платежом. Если эти характеристики отвечали сформированной модели, она считалась условно безопасной. Если же поведение клиента расценивалось как нетипичное, событие попадало в другую форму обработки, которая требовала дополнительного подтверждения.
В конце концов мы остановились на решении разработки RSA, и опыт внедрения этой системы нас удовлетворил. Основная задача — снижение стоимости обнаружения одного мошеннического платежа — была достигнута. А кроме того, и нагрузка на фронтальную сеть при обнаружении снизилась почти в десять раз.
Можно ли привести какие-то оценки с точки зрения ущерба?
Например, в форме № 203, которую мы сдаем в Центральный банк, фиксируя в ней инциденты и ущерб, за весь год фигурировала информация лишь о трех предотвращенных попытках мошенничества. По сравнению с предыдущими отчетными периодами это ничтожно мало. В год, оказавшийся пиковым для попыток проведения мошеннических платежей, мы фиксировали в среднем полтора инцидента в день — реализованных сценариев было, естественно, гораздо меньше.
Может быть, какие-то инциденты остаются для банка незамеченными?
Думаю, если у клиента воруют деньги, он это без внимания не оставит. Мало кто из них не следит за состоянием своего счета, в противном случае бухгалтера такой компании надо немедленно увольнять. Даже если сценарий злоумышленника основан на микроскопических суммах, транзакций будет много. А бухгалтерия вообще не оперирует определениями типа «микроскопическая сумма» или «ошибка округления».
При выявлении несоответствий будет кричать и истерить?
Еще как! Причем тем больше будет волноваться, чем меньше ошибка, поскольку ее труднее найти. Бухгалтер клиента — наш главный соратник при выявлении мошеннических операций.
Как можно описать инфраструктуру, на которую легло решение RSA? Какие базы данных используются при анализе инцидента?
СУБД, способных поддерживать такой объем данных, не так много. Корпоративным стандартом нашего банка является платформа Oracle, но RISK-процессорами, предложенными Oracle, мы остались не очень довольны, поэтому планируем переход на процессоры Intel. И скорее всего будем рассматривать технологию виртуализации.
В чем причина вашего недовольства?
Проблемы проявились самым неприятным образом и в самое неподходящее время, после чего мы пересмотрели свою концепцию в отношении технических средств Oracle. Компьютеры и серверы SUN, пока они были именно SUN‘овскими, считались одними из лучших, но после слияния SUN Microsystems с Oracle они перестали нас устраивать.
Как вы планируете перейти на виртуализацию?
Мы ее уже тестировали. Все те же продуктовые серверы будут переведены на внутреннюю виртуализацию, а варианты внешних облаков или ЦОДов мы пока не рассматриваем. Мне проще создать внутреннее облако (как бы распределенное, но именно внутреннее), поскольку так легче все процессы держать под контролем.
Но вернемся к оценке результатов борьбы с мошенничеством в системах ДБО. Проводится ли в банке какой-то анализ затрат и их эффективности?
Это довольно сложная проблема, поскольку при уводе денег у клиента банк не несет прямых материальных убытков. И даже если клиент потребует от банка возмещения ущерба, шансов выиграть судебное дело у него будет немного. Однако мы ощущаем ответственность за клиента и принимаем на себя его риски. Мы хотели построить систему так, чтобы она изначально была ориентирована на работу с уже зараженным рабочим местом клиента. Другими словами, концепция такова: мошенники успели заразить клиента, но нам все равно нужно проводить его платежи. Исходя из этого мы и строили систему безопасности.
Такой подход принципиально изменяет всю парадигму бизнеса, поэтому я могу обосновать затраты не на снижение количества мошеннических операций, а на поддержание уровня безопасности. В любой банковской системе «моментом истины» является контрольный звонок клиенту: он должен подтвердить платеж именно по тому телефону, который мне представил и по которому я звоню (а не клиент звонит в банк с запросом на проведение платежа). Мало того, номер является защищенным, и мошенник не может его изменить, чтобы мой звонок поступил к нему, а не к клиенту. Операционист банка располагает специальным скриптом, который он называет при звонке, а клиент должен ответить. И только после этого проводится подозрительный платеж.
А вот теперь — о результатах внедрения доработанного продукта RSA. Скажем, всего под контроль подпадает 20 тыс. платежей в день, а в банке — 400 операционистов. Получается нереальный объем работы, звонков и переговоров с клиентами. А если каждый операционист должен будет проверить 10–15 платежей в день, то это уже реально.
Как удается сократить количество звонков?
Путём правильной настройки параметров безопасности, их постоянного анализа и периодической коррекции. Например, уровень риска, на который мы реагируем, зависит от огромного количества причин. Модель рисков формируется в результате анализа почти двухсот параметров, и любой из них может привносить что-то свое в конечную картину. Каждому параметру присвоен свой вес, но даже самый маленький может повлиять на установленный уровень реагирования, причем границы могут «плавать». Допустим, свыше 600 — это фрод, 599 — еще не фрод, но уже контрольный звонок, 300 — точно не фрод, а 301 — надо посмотреть…
А почему бы эти границы сразу не завысить или не занизить, чтобы потом уже со всем этим не заморачиваться?
Завысив границу, вы получите огромное количество ложных срабатываний, а внедрять систему, реагирующую на всё, попросту бессмысленно. А если границу занизить, немало инцидентов можно и прозевать. Антифродовая система — «живая», и ее должен поддерживать в актуальном состоянии специалист, который получает внутреннюю оценку на основе ежедневного анализа ее работы. А для этого нужно, тоже ежедневно, мониторить и обрабатывать все платежи с сомнительным статусом.
Изменился ли штат службы безопасности после введения в эксплуатацию системы противодействия мошенничеству в ДБО?
В нем появились еще два сотрудника. Если точнее, то один, но в двух лицах, поскольку надо обеспечить рабочие дни с учетом часовых поясов и замену в случаях отпусков или командировок.
Каковы компетенции этих сотрудников? Кто они — технари или аналитики?
Формально один из них числится аналитиком, а второй — офицером безопасности. Однако на деле оба являются аналитиками: один — чуть более сильным, другой — послабее. Зато он сильнее как офицер безопасности. Эти сотрудники друг друга очень хорошо дополняют.
Решение, использованное в вашем банке, можно считать уникальным?
Любая технология антифродовой системы по-своему уникальна. Тиражировать ее можно, но она все равно будет значительно кастомизироваться под каждый конкретный банк. Тем не менее можно сформулировать общие принципы, которые удастся тиражировать и не имея дорогой покупной системы.
Так, каждый банк может разработать для себя не более пяти правил простой фильтрации, которые «отобьют» 90% мошеннических операций. Самое простое правило — IP-фильтрация рабочего места на компьютере. Далее может быть так называемый fingerprint, цифровой слепок с внутреннего номера процессора и настройки операционной системы. Если какой-то параметр меняется, значит, что-то изменилось и в ОС.
Наиболее сильный способ (как правило, он является самым безотказным, но и самым затратным) — контроль над всеми платежами, поступающими по новому адресу. При этом необходимо сразу выделить категорию платежей, которые вообще не контролируются: чаще всего сюда входят платежи по бюджетам, налогам и пр. Остальные платежи, если они идут по новому адресу, нужно ставить под контроль.
Для того чтобы минимизировать число контрольных звонков, можно, скажем, обязать клиента подтверждать платежи по дополнительному каналу, не связанному с его компьютером. Самый лучший вариант, наиболее простой и эффективный, — применение одноразового пароля подтверждения. Но эта штука не работает по подтверждению контента документа, она подтверждает только факт отправки сообщения, а вот подтвердить его содержимое не умеет. Для подтверждения содержимого можно попробовать по какой-нибудь линии PUSH или по USSD присылать сообщения, которые будут содержать, например, ключевые параметры платежей — суммы и номера счетов и ещё какие-то контрольные числа, зависящие от этих параметров. Если я вижу, что все ключевые данные в моем платеже, отправленном в банк, и в сообщении из банка совпадают, то ввожу полученное контрольное число. И чем независимый канал проще и менее подвержен заражению, тем больше возникает уверенности в том, что платеж окажется правильным.
Если у вас есть такой механизм, то он дорогого стоит. Это и есть антифродовая система.
На какое время хватит потенциала системы, которая сейчас построена в банке? Ведь очевидно, что злоумышленники тоже не стоят на месте.
Если жестко реализовать принцип контроля над новыми платежами и руководствоваться представлением о том, что компьютер клиента изначально заражен, то для меня не имеет значения, чем пользуется мошенник для реализации своих целей. Главное, о чем я должен думать, — как из платежей, формируемых на зараженном компьютере, выбрать те, которые хочет сделать сам клиент. Мне кажется, использование нашей антифродовой системы вкупе со столь нехитрыми правилами позволит банку защищать своих клиентов года два-три. Но расслабляться не следует — за это время, а то и раньше мошенники могут придумать что-то кардинально новое или появится антифродовая система, основанная на совершенно иных принципах работы.
С Василием Окулесским беседовал Олег Седов, главный редактор BISA
