Предложение по решению проблем обеспечения защиты в системах обработки больших данных в финансово-кредитных организациях. ЧАСТЬ 3.

1   2   3

---

3. Предложение по решению проблем обеспечения защиты в системах обработки больших данных в финансово-кредитных организациях

 

3.1. Технологии структуризации данных для выявления утечек и уязвимостей

 

При проведении онлайн-платежа при покупке товара или услуги через сеть Интернет полная цепочка имеет вид, представленный на рисунок 3.1.

Рисунок 3.1 – Жизненный цикл транзакций с различными типами риска

Необходимо пояснить некоторые детали приведенной схемы.

Под мерчантом понимается продавец товара или услуги. Это – веб-приложение, в котором для клиента доступна возможность оплаты выбранного товара или услуги.

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

Электронная платежная система (ПС) представляет собой сервис, который принимает к оплате электронные деньги, банковские карты через сеть Интернет. В качестве примеров платежных систем можно упомянуть о WebMoney, Яндекс.Деньги и т.п.

Банком-эквайром называется банк, осуществляющий предоставление услуг, связанных с обработкой платежей по банковским картам.

Международная платежная система (МПС) является системой расчетов между банками, зарегистрированных в различных государствах, использующих единые стандарты платежных средств. В качестве примеров международных платежных систем можно упомянуть о MasterCard, American Express, Visa.

Банком-эмитентом называется банк, осуществивший выпуск банковской карты, которая используется клиентом для оплаты товара или услуги.

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

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

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

Вместе с тем, и игнорирование фрода со стороны мерчанта не представляется возможным. В самом удачном случае произойдет недополучение денежных средств за платежи мошеннического характера мерчантом (даже в случае уже оказанной услуги), в самом крайнем же случае на мерчанта будут еще и возложены штрафные санкции. Размер этих санкций минимально может составлять около 100 рублей и может расти пропорционально в соответствии с объемом транзакций мошеннического характера. Также, если количество фрода достаточно велико, ведущие международные платежные системы (MasterCard, Visa) могут подвергнуть мерчанта весьма неприятным санкциям.

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

3-D Secure (Three-Domain Secure) является защищенным протоколом, осуществляющим добавление дополнительного уровня безопасности для дебетовых и онлайн-кредитных карт. Реально его можно рассматривать в виде двухфакторной идентификации владельца карты. Целью разработки данной технологии являлось обеспечение безопасности оплаты товаров и услуг в сети Интернет. Изначально данный протокол был предложен платежной системой Visa, а затем, подвергшись определенным изменениям, был взят на вооружение и другими. У Visa данный протокол имеет название Verified by Visa (VbV), у MasterCard – Mastercard SecureCode (MCC), а у JCB International – J/Secure.

Данным протоколом осуществляется добавление дополнительного шага авторизации пользователя при оплате покупки в интернет-магазине. Первый этап подразумевает использование номера карты, срока ее действия, имени держателя карты и кода проверки ее подлинности (например, CVC2). На втором этапе с помощью протокола 3-D Secure сайт магазина отображает страницу банка-эмитента карты, на которой пользователь должен выполнить ввод дополнительного защитного кода. Он может быть получен клиентом банка посредством, например, SMS-сообщения на собственный мобильный телефон, с помощью карты разовых кодов или специализированного устройства. Кроме того, код может быть постоянным и установлен самим клиентом заранее. Вообще говоря, название метода Three-Domain Secure объясняется тем, что в онлайн-транзакции принимают участие три домена – домен мерчанта (торговой точки) или эквайрера, где осуществляется ввод данных платежной карты, домен платежной системы, выполняющей переадресацию платежа на страницу подтверждения разовым кодом или паролем, а также домен эмитента карты или специализированного сервиса, где происходит формирование страницы подтверждения и проверка корректности введенных защитных кодов.

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

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

Однако нельзя забывать, что при добавлении шагов, принуждающих пользователя к дополнительным действиям, может наблюдаться стремительное снижение числа успешно завершенных транзакций. В соответствии с результатами исследования, проведенного некоторыми исследователями, включение 3-D Secure на территории Российской Федерации влечет за собой снижение количества успешных платежей в размере 20-27%.

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

PCI DSS (Payment Card Industry Data Security Standard) является стандартом безопасности данных сферы платежных карт. По сути, представляет собой совокупность требований, направленных на обеспечение безопасности хранения и передачи платежных данных. Разработка стандарта осуществлена Советом по стандартам безопасности индустрии платежных карт (Payment Card Industry Security Standards Council, PCI SSC), к учреждению которого приложили руку такие международные платежные системы, как MasterCard, JCB, Discover, American Express, Visa.

В данном стандарте содержится двенадцать требований:

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

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

Стандарт PCI DSS ориентирован на выполнение следующих аспектов:

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

С более полной информацией по данному стандарту можно ознакомиться на сайте Official PCI Security Standards Council Site.

Также при разработке антифрод-сервиса следует не забывать о некоторых существующих законодательных ограничениях, касающихся хранения/обмена персональных и платежных клиентских данных. В Российской Федерации это закон «О персональных данных» (152-Ф3).

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

Именно этим и объясняются повышенные предъявляемые требования к безопасности хранения данных, надежности работы, возможностям, связанным с масштабированием системы.

В коллективе, ориентированном на разработку антифрод-системы, внимания заслуживают следующие роли и области ответственности этих ролей:

• эксперт в предметной области. В данном случае имеются в виду следующие предметные области: банковские системы, платежные системы, оплата через сеть Интернет, юридическая специфика функционирования подобных систем;
• разработчик. Для сотрудника, выполняющего данную роль, необходимо владение высокоуровневым языком программирования, многопоточным и асинхронным программированием, а также наличие достаточно высокой математической подготовки;
• project manager. Занимается координацией разработки;
• data scientist. Сфера ответственности – исследование процессов, обработка данных с полноценным применением соответствующего математического аппарата;
• архитектор – осуществляет проектирование надежного высокодоступного (в идеале еще и масштабируемого и распределенного) приложения.

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

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

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

 

3.2.  Анализ имеющихся данных на аномалии путем их классификации

 

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

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

Выбор атрибутов качества напрямую следует из типа проектируемой системы, а именно – business critical. Итак, выделяются следующие атрибуты:

• отказоустойчивость;
• надежность;
• значительная масштабируемость;
• распределенность.

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

Фактически, на высоком уровне (около 81-го) сертификации стандарта PCI DSS допускается хранение PAN в зашифрованном виде.

Помимо требований, предъявляемых стандартом PCI DSS, не следует забывать об обязательности выполнения закона «О персональных данных» (152-Ф3).

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

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

Собрав все ограничения, относящиеся к юридической сфере, можно добавить к проектируемой системе ряд следующих требований:

• запрет хранения PAN и CVV платежной карты в каком-либо виде;
• хранение других данных платежа производится только в защищенном виде;
• передача данных между мерчантом (программным клиентом) и антифрод-системой должна осуществляться исключительно по защищенным каналам;
• все операции должны производиться только с персонифицированными данными.

Теперь можно переходить к формулировке требований функционального характера.

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

• реализация возможности предоставления клиенту API для передачи информации о платеже;
• предоставление клиенту API для модификации (корректировки) платежных данных;
• обязательное уведомление клиента о результатах предсказания, отнесен ли платеж к мошенническим.

Помимо этого, к API предъявляется некоторое количество требований нефункционального характера, среди которых ключевыми являются:

• предоставление общедоступного протокола взаимодействия с клиентом;
• ведение взаимодействия с клиентом исключительно через защищенные каналы связи.

Безусловно существует совокупность бизнес-требований, предъявляемых к проекту разработки антифрод-системы. Рассматривая внутреннюю логику антифрод-системы, можно выделить только одно значимое бизнес-требование, заключающееся в обязательности прогнозирования в соответствии с информацией о платеже, будет ли пропущена или блокирована транзакция. В ходе реализации данного требования будет предпринята попытка доказательства, что платеж будет отклонен. Целесообразно рассмотрение основных причин отказа в проведении транзакции. Среди них выделяются следующие: формирование данных было осуществлено некорректно, либо транзакция отнесена к мошенническим. Далее будут разобраны методы анализа каждой из указанных причин.

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

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

Алгоритм Луна (Luhn algorithm) является алгоритмом определения контрольной цифры номера пластиковой карты. Основное его назначение – определение ошибок, причиной которых является непреднамеренное искажение данных. Следует отметить, что по результатам выполнения данного алгоритма можно только с определенной степенью достоверности утверждать о том, что в номере карты отсутствуют ошибки.

Номер пластиковой карты обычно состоит из:

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

Данный алгоритм был предложен немецким компьютерным специалистом Гансом Луном в 1954 году. Алгоритм Луна базируется на простом правиле вычисления контрольной суммы для проверки идентификационных номеров, в частности, номеров пластиковых карт. Целью разработки алгоритма являлось определение ошибок при вводе номера. В данном алгоритме предусмотрено определение ошибки ввода одной некорректной цифры, а также практически всех перестановок соседних цифр, кроме перестановки 09-90, а также обратной 90-09.

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

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

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

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

Исходя из вышеперечисленного, целесообразно перечисление только ключевых и показавших наибольшую эффективность эвристик:

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

Тут же возникает вопрос – как количественно определиться с термином «множество»? Какой период времени может быть отнесен к коротким (10 секунд или три недели)? Как может быть решена проблема неравенства веса фильтра  весу фильтра  при условии, что значения их весов должны изменяться в динамическом режиме в ходе функционирования приложения?

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

 

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

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

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

Глобальные фильтры могут принадлежать как к статическому, так и к динамическому типу, они могут быть взаимосвязаны как с определением аномальной активности (адрес IP), так и с определенными бизнес-правилами (мерчантом отклоняются все платежи, совершенные из Уругвая) и т.д.

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

Рисунок 3.2 – Жизненный цикл транзакций с различными типами риска

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

 

3.3. Конфигурирование механизмов защиты и мониторинга

 

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

Общая архитектура разрабатываемой системы представлена на рисунок 3.3.

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

Рисунок 3.3 – Архитектура разрабатываемого антифрод-сервиса

В разработанный антифрод-сервис входят следующие системы:

• Antifraud API Service – сервис типа REST, осуществляющий предоставление API для взаимодействия с сервисов Fraud Predictor ML;
• Transactions Log (журнал транзакций) – NoSQL хранилище, в котором содержится вся информация о транзакциях;
• Fraud Predictor ML – сервис выявления платежей мошеннического характера, основанный на использовании алгоритмов машинного обучения.

Кроме того, сервис обладает многочисленными программными клиентами (Clients). Они фактически являются веб-приложениями мерчантов, либо js-виджетами, выполняющими вызов REST-сервисов Antifraud API Service.

Принципиальная архитектура взаимодействия перечисленных систем представлена на рисунок 3.3.

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

При использовании антифрод-системой сервисов Azure – Cloud Service для веб и рабочих ролей, Azure Queue, Azure Table, Azure ML помимо практического полного отсутствия необходимости в начальных финансовых затрат можно говорить о следующих ключевых конкурентных преимуществах:

• наличие высокой доступности: уровень SLA составляет не менее 99,96%;
• обеспечение безопасности хранения: соответствие сертификатам ISO 27001/27002, а также PCI DSS0;
• обеспечение высокой масштабируемости: предусмотрено масштабирование в автоматическом режиме количества рабочих узлов в соответствии с нагрузкой, партицирование таблиц хранилища NoSQL на базе PartitionKey;
• приемлемая отказоустойчивость: доступен (и даже рекомендован) запуск всех рабочих узлов в нескольких экземплярах;
• высокая надежность хранения: существующие системы хранения данных обладают значительной избыточностью.

Кроме этого, можно отметить ряд менее значимых достоинств:

• наличие глубокой интеграции с Microsoft Visual Studio;
• наличие удобного мониторинга приложения.

Однако все эти преимущества (достоинства) стали доступными из-за первоначального замысла разработки антифрод-сервиса под облачные технологии. Таким образом:

• веб и рабочие узлы относятся к stateless (любой ответ не зависит от состояния);
• сетевые взаимодействия осуществляются исключительно в асинхронном режиме и только с использованием retry-политик (Retry Pattern);
• выравнивание нагрузки и гарантированная обработка задач осуществляется с помощью очередей сообщений (паттерн Queue-Based Load Leveling Pattern);
• наличие горизонтального партицирования для хранения структурированных или полуструктурированных данных (Sharding Pattern).

Помимо этого, антифрод-система является так называемой near real-time системой, поэтому в процессе реализации антифрод-сервиса:

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

Функционирование MapReduce включает два этапа: Map и Reduce, получивших свое название по аналогии с одноименными функциями высшего порядка map и reduce.

На Map-этапе осуществляется предварительная обработка входных данных. Для этого на один из компьютеров (он называется главным узлом – master node) поступают входные данные задачи, после чего он выполняет разделение их на части с последующей передачей другим компьютерам (они называются рабочие узлы – worker node) для обработки предварительного характера.

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

Достоинство MapReduce состоит в его возможности распределенного выполнения операций предварительной обработки и свертки. Работа операций предварительной обработки осуществляется независимо друг от друга, они могут выполняться в параллельном режиме (хотя в практических задачах всегда существуют ограничения, связанные с источником входных данных и/или числом используемых процессоров). Аналогично, свертка может выполняться множеством рабочих узлов – для этого необходимым является только выполнение условия, при котором обработка всех результатов предварительной обработки, имеющих одно конкретное значение, выполнялась одним рабочим узлом в один момент времени. Вместе с тем, эффективность данного алгоритма может быть меньше, чем у более последовательных алгоритмов. Применение MapReduce возможно к большим объемам данных, обработка которых может вестись большим числом серверов. Например, MapReduce вполне подходит для решения задачи сортировки петабайта данных, причем время выполнения не будет превышать нескольких часов. Благодаря параллелизму появляются определенные возможности, связанные с восстановлением после частичных сбоев серверов: при возникновении сбоя в рабочем узле, который производит операцию предварительной обработки или свертки, допустима передача его работы другому рабочему узлу (при условии доступности входных данных для осуществляемой операции);

• принимаются меры для предотвращения блокировок лога транзакций (любых распределяемых ресурсов). Для этого к информации о транзакции добавляется поле timestamp;
• удаляются долгие запросы;
• для таких операций, как сохранение единичной записи в логе транзакций, используется подход Push’n’Forget (точность работы алгоритма особенно не пострадает от пропажи одной записи из 10К успешно сохраненных).

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

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

Далее необходимо кратко остановиться на принципах взаимодействия между компонентами антифрод-сервиса. С точки зрения мерчанта сервис является REST-сервисом, с которым возможно взаимодействие посредством протокола https – Antifraud API Service. Antifraud API Service осуществляет свою работу в кластере, в состав которого входят несколько веб-ролей типа stateless (под веб-ролью в Azure следует понимать слой приложения, играющий роль веб-приложения).

На диаграмме последовательностей (рисунок 3.4) выполнено описание возможных взаимодействий мерчанта с каждой из подсистем антифрод-сервиса.

Целесообразно описание работы данной диаграммы по этапам (шагам):

• этап 1: выполняется отправка запроса, содержащего данные о платеже;
• этап 2: осуществление трансформации модели (в терминах MVC);
• этап 3: производится отправка запроса на сервис, отвечающий за предсказание результата платежа;
• этап 4: происходит возврат результата – будет ли проведен платеж (или отклонен);
• этап 5: выполняется сохранение данных;
• этап 6: производится возврат результата клиенту;
• этапы 7, 8: выполнение пересчета и обновления обучающей выборки; после этого происходит переобучение модели;
• этапы 9-12 (могут быть опущены). Со стороны Клиента осуществляется инициация отправки запроса, содержащего данные о результате платежа (для случая, когда результат предсказания не совпадает с реальным результатом платежа, который был передан в запросе).

Рисунок 3.4 – Диаграмма последовательностей взаимодействия подсистем сервиса

Теперь будет выполнено более подробное рассмотрение каждого из этапов.

Запрос от мерчанта подается на Контроллер (в терминах MVC) (этап 1). Далее с полученной моделью (в терминах MVC) происходит следующее:

• трансформация из модели контроллера в доменный объект;
• отправка запроса на внешние геолокационные сервисы (Azure Marketplace) для определения страны в соответствии с индексом плательщика и страны в соответствии с IP хоста, с которого было зафиксировано поступление запроса на снятие средств с карты;
• выполнение этапа проверки через глобальные фильтры;
• выполнение этапа проверки платежных данных на валидность;
• осуществление предварительного анализа полученной транзакции – выполняется вычисление эвристики для таймфреймов продолжительностью в 5 секунд, 1 минута, 24 часа;
• выполнение сокрытие личных данных держателя карты и платежных данных – фактически, это хэширование имени держателя карты, имени владельца аккаунта на сайте мерчанта, адреса плательщика, его телефона, адреса электронной почты;
• удаление неиспользуемой информации – например, данные, свидетельствующие о сроке действия карты, после этапа 4 будут далее не нужны.

Подробное описание эвристик, глобальных фильтров и признаков валидности данных платежа было выполнено в предыдущем разделе.

На этапе 2 осуществляется трансформация объекта предметной области в объект DTO, который:

• отправляется в сервис Fraud Predictor ML (этап 3);
• после получения ответа от Fraud Predictor ML (этап 4) производится сохранение в лог транзакций данных о транзакции и ее результате (этап 5);
• осуществляется возврат клиенту ответа, касающегося предсказанного результата платежа (отнесен ли он к мошенническим или нет).

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

• структура их формата: <transaction_id, transaction_result, last_update_time>;
• выполняется обработка запросов в Merchant API Service и после валидации они поступают в Azure Queue (отказоустойчивый сервис очередей).

Из очереди запросы извлекаются одним из роботов, которые, фактически, являются рабочими ролями типа stateless (под рабочей ролью в Azure следует понимать слой приложения, на который аозложена роль обработчика).

Теперь пришло время детального разбора хранилища данных.

В лог транзакций осуществляется сохранение как данных о транзакциях, так и дополнительной информации, касающейся их (чаще всего, это статистические данные). Лог транзакция является долговременным хранилищем на основе Azure Table (сервис, который может быть описан как отказоустойчивое хранилище типа NoSQL (key-value)).

В логе транзакций содержатся две таблицы:

• таблица, в которой содержатся факты о транзакции. Она называется TransactionsInfo. Ее структура: id транзакции (Row Key), id мерчанта, хэш имени держателя платежной карты (в случае его доступности), сумма платежа, валюта платежа и т.д.;
• таблица, в которой хранятся рассчитанные статистические метрики. Ее название – TransactionsStatistics. В ней содержится информация, характеризующая: сколько раз были осуществлены платежи с данной карты (несколько таймфреймов), количество IP были произведены платежи, значение временного интервала между платежами, с какого времени выполнена регистрация покупателя у мерчанта, сколько раз были осуществлены проведенные (успешные) платежи и т.д.

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

 

3.4.  Предложения по технологии организации реагирования на инциденты

 

После разработки проекта антифрод-системы целесообразным является начальное его тестирование. Для этого предлагается обучение четырех моделей с использованием алгоритмов логистической регрессии, метода опорных векторов, дерева решений и персептрона. Из обученных моделей будет выбрана модель, обладающая наибольшей точностью на тестовой выборке, после чего будет осуществлена ее публикация в виде сервиса REST/JSON. После этого необходимо написание программного клиента и проведение нагрузочного тестирования на сервисе REST.

Вначале создается новый эксперимент в Azure ML Studio. Его конечный вид представлен на рисунок 3.5. Каждому из элементов эксперимента ставится в соответствие этап последовательности, осуществляемый data scientist в ходе обучения модели.

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

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

Рисунок 3.5 – Структура эксперимента

В качестве набора данных для модели, ориентированной на определение платежей мошеннического типа, будет использован лог транзакций, в состав которого входят две таблицы в NoSQL-хранилище (Azure Table): таблица, содержащая фактическую информацию о транзакциях (TransactionsInfo) и таблица, содержашая предварительно вычисленные статистические метрики (TransactionsStatistics).

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

Далее выполняется Inner Join загруженных таблиц в соответствии с полем TransactioId. Используя элемент управления Metadata Editor, существует возможность указания типов данных (timestamp, integer, string), пометки столбца, в котором содержатся ответы (label), а также столбцов с предикторами (features). Кроме этого выполняется пометка типа шкалы у этих данных: абсолютные, номинальные.

Этап подготовки обладает большой важностью при создании адекватной модели. Можно проиллюстрировать данный тезис на конкретном примере, касающемся валюты платежа, хранение которой осуществляется в виде кодов ISO (тип – целочисленное значение). В кодах ISO используется классификационная (номинальная) шкала. Однако сомнительно ожидать автоматического определения со стороны системы, что в столбце «Currency» осуществляется хранение не целочисленного значения с абсолютной шкалой (другими словами, доступными являются операции типа + и >). Данное правило достаточно неочевидно, и в системе нет никакой информации о нем.

В наборе данных могут содержаться пропущенные значения. В данном случае, определение IP-адреса плательщика и его страны не всегда представляется возможным, поэтому в данных полях могут находиться пустые значения. После проверки имеющегося набора данных выполняется замена пустых значений стран на «undefined», используя при этом элемент управления Clean Missing Data. Этот же элемент управления поможет выполнить удаление строк, в полях держатель карты, валюта или сумма платежа которых присутствуют пустые значения, поскольку данные строки заведомо заполнены некорректными данными, то есть они являются источником шума в модели.

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

Наконец, используя элемент управления Normalize Data осуществляется ZScore-нормализация данных, в которых содержатся слишком большие числовые значения. Таким значениям может быть сумма платежа (расположенная в столбце TransactionAmount).

Далее выполняется разделение полученного набора данных, соответственно, на обучающую и тестовую выборки. Важно осуществить корректный выбор соотношения данных в обучающей выборке и в тестовой. В данном случае, используя элемент управления Split, в обучающую выборку переносится 75% данных с дополнительным включением режима смешивания данных (установка флага Randomized split) при разделении на поднаборы данных. Благодаря режиму смешивания данных при разделении появляется возможность недопущения «перекосов» в обучающей выборке, появляющихся из-за больших утечек номеров пластиковых карт (и, в результате, аномальной активности фрод-роботов в данный период).

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

В Azure ML существует возможность подключения в одном эксперименте сколь угодно большого количества алгоритмов машинного обучения. Это позволяет на этапе исследования осуществить сравнение производительности нескольких алгоритмов для определения того, который в наибольшей степени соответствует решаемой задаче. В данном случае используется нескольку алгоритмов, принадлежащих к так называемой двухклассовой классификации: логистическая регрессия (Two-Class Logistic Regression), метод опорных векторов (Two-Class Support Vector Machine), нейронная сеть (Two-Class Neural Network) и дерево решения, построенное с помощью метода градиентного спуска (Two-Class Boosted Decision Tree).

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

Заключительный этап состоит в просмотре получившихся данных элемента управления Evaluate Model (соответствует команде Visualize из контекстного меню элемента). Отображение данных представлено для каждого из используемых алгоритмов.

В элементе управления Evaluate Model содержится матрица неточностей (confusion matrix), графики ROC и Precision/Recall, а также рассчитанные параметры точности алгоритма Recall, Accuracy, F1 Score, Precision и AUC. Немного упрощая, требуется выбор алгоритма, значения Precision, AUC и Accuracy которого наиболее близки к единице, вогнутость графика ROC в сторону оси ординат как для обучающей, так и для тестовой выборки максимальна.

Помимо этого, следует изучить изменения AUC в соответствии с устанавливаемым значением Threshold. Для фрод это является важным, поскольку величина стоимости нераспознанных платежей мошеннического характера (False Positive) значительно превышает величину стоимости платежей, которые ошибочно были приняты за фрод (false Negative).

В такой ситуации требуется подбор значения Threshold, не совпадающего со значением по умолчанию (оно установлено равным 0,5).

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

В результате проведенного эксперимента лучшей точностью обладает алгоритм двухклассовой нейронной сети (Two-Class Neural Network) (показатели точности представлены на рисунок 3.6), после него – алгоритм построения дерева решения с помощью метода градиентного спуска (Two-Class Boosted Decision Tree).

Рисунок 3.6 – Результаты алгоритма нейронной сети

После получения модели, функционирующей с приемлемой точностью, необходима публикация проведенного эксперимента в виде веб-сервиса. Для операции публикации требуется нажатие кнопки «Publish Web Service» в Azure ML Studio. Далее идет выполнение тривиальных процедур.

Результатом будет являться развертывание Azure ML отказоустойчивого (SLA 99,96%) масштабируемого веб-сервиса. После публикации сервиса будет получен доступ к странице документации по API сервиса, которая называется API help. На ней выполнено общее описание сервиса, а кроме того, описаны форматы ожидаемых входных и выходных сообщений, и примеры вызова данного сервиса на языках высокого уровня Python, C# и R.

Основной принцип вызова разработанного сервиса со стороны программного клиента представлен на рисунок 3.7.

Рисунок 3.7 – Схема вызова сервиса

Разработанная система, безусловно, обладает рядом ограничений. Так в качестве одного из узких мест можно говорить, непосредственно, о самой системе Azure ML. Поэтому важным является понимание ограничений Azure ML в целом, а также веб-сервисов Azure ML. Однако данный вопрос плохо освещен как в официальной документации, так и в соответствующем community.

Нет практически никакой информации, касающейся throttled policy конечных точек веб-сервиса Azure ML: неизвестно наибольшее допустимое значение параллельных запросов веб-сервису Azure ML (в ходе тестирования эмпирически было проверено значение 25 параллельных запросов на одну конечную точку), а также максимально возможный размер, которым может обладать принимаемое сообщение (это актуально для работы сервиса в пакетном режиме).

Менее важно, однако существует вопрос, связанный с наибольшим допустимым размером входных данных (Criteo Labs был размещен набор данных, имеющий размер в 1 Тб), наибольшим числом прецедентов и предикторов, которые могут быть переданы на вход алгоритма машинного обучения в Azure ML.

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

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

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

• обязательное осуществление проверки платежей, как с применением технологий, принятых в конкретной отрасли (fingerprint и т.д.), так и с применением собственных накопленных о клиенте знаниях (история заказов, например);
• проведение интерпретации результата с использованием следующего алгоритма: при вероятности фрода менее 0,35 оплата может приниматься без 3-D Secure, при значении вероятности в интервале 0,35-0,90 оплата должна приниматься с включенным 3-D Secure, при значении вероятности фрода выше 0,9 платеж должен быть блокирован;
• необходимо осуществлять выбор уровней, описанных выше, основываясь на собственных аналитических исследованиях с систематическим пересмотром их (выполнение минимизации упущенных выгод и штрафов, причиной которых является фрод).

 

Заключение

 

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

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

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

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

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

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

 

Список использованных источников

 

1. ГОСТ Р 57580.1-2017 Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер (Издание с Поправкой). Дата введения 2018.01.01. М. Стандартинформ, 2020. 34 с.
2. ИCO/МЭК 29115:2013 (ISO/IEC 29115:2013) Информационная технология. Техника безопасности. Схема обеспечения идентификации объекта. Введен: 04.2013. 44 с. – Режим доступа. – URL: https://www.iso.org/ru/standard/45138.html.
3. Постановление Правительства Российской Федерации от 1 ноября 2012 г. N 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». Собрание законодательства Российской Федерации, N 45, 05.11.2012, ст.6257. – Режим доступа. – URL: http://docs.cntd.ru/document/902377706.
4. Приказ ФСТЭК России от 6 декабря 2011 г. N 638. «Требования к системам обнаружения вторжений». Введен в действие: 15.03.2012. – Режим доступа. – URL: https://fstec.ru/normotvorcheskaya/poisk-po-dokumentam/118-tekhnicheskaya-zashchita-informatsii/dokumenty-po-sertifikatsii/prikazy/394-informatsionnoe-pismo-fstek-rossii
5. Центральный банк Российской Федерации. Положение «О требованиях к защите информации в платёжной системе Банка России» от 23.12.2020. N 747-П. – Режим доступа. – URL: http://www.cbr.ru/Queries/UniDbQuery/File/90134/1243.
6. Центральный банк Российской Федерации. Положение «О платежной системе Банка России» от 24 сентября 2020 г. N 732-П. – Режим доступа. – URL: https://www.cbr.ru/PSystem/acts/.
7. Болонин А.И. Мошенничество в электронных платежных системах // Вестник Академии. 2016. № 1. Т. 77-80.
8. Варламова С.Б., Васильев Ю.А. Классификация способов мошеничества в банковских IT-технологиях и современные методы защиты от фрода // Финансовые рынки и банки. 2019. № 2. С. 41-44.
9. Вельц С.В. OMNIREACT — кросс-канальный фрод-мониторинг // Свидетельство о регистрации программы для ЭВМ RU 2018666995, 27.12.2018. Заявка № 2018660981 от 28.09.2018.
10. Верхотуров В.К., Ткаченко С.Н. Использование машинного обучения в системах фрод-мониторинга // В сборнике: Cборник методических рекомендаций по вопросам развития технических и естественных наук. Нижний Новгород, 2019. С. 52-59.
11. Гришина Е.А. Риски в платежных системах: мошеннические схемы в мире банковских карт // Финансы и кредит. 2018. Т. 24. № 6 (774). С. 1280-1291.
12. Журин В.О. Основные проблемы при разработке системы фрод-мониторинга на основе машинного обучения // В сборнике: Научные исследования: теоретико-методологические подходы и практические результаты. Материалы международной научно-практической конференции НИЦ «Поволжская научная корпорация». 2018. С. 210-213.
13. Замятина Е.В., Луценко А.В. Влияние фрод — мониторинга на экономическую безопасность коммерческом банке // В сборнике: Инструменты и механизмы современного инновационного развития. сборник статей Международной научно-практической конференции. 2018. С. 71-75.
14. Кашина Ю.А. Особенности преступлений в сфере безналичных расчетов с использованием банковских карт // Бюллетень науки и практики. 2018. Т. 4. № 5. С. 574-582.
15. Копелиович Д.И., Журин В.О. Сравнительная характеристика систем фрод-мониторинга. Основные подходы к построению механизма обнаружения // Современные научные исследования и разработки. 2018. № 3 (20). С. 302-304.
16. Левашов М.В., Кухаренко А.В. Эффективность критерия отношения правдоподобия в статистической модели фрод-мониторинга в интернет-банкинге // Вопросы защиты информации. 2018. № 2 (121). С. 66-71.
17. Левашов М.В., Овчинников П.В. Эффективность классификаторов для выявления фрода в финансовых транзакциях // Вопросы кибербезопасности. 2019. № 5 (33). С. 63-69.
18. Ляхова А.О., Элмурадов Т.Д. Мошенничество в интернете и способы защиты от нее // Теория и практика современной науки. 2020. № 3 (57). С. 157-159.
19. Медведева М.Б., Васин М.М. Проблемы защиты от мошенничества в операциях с платежными картами в системе КБО физических лиц и развитие ее законодательного обеспечения // Финансовые рынки и банки. 2019. № 1. С. 30-35.
20. Нечаев А.В. Антифрод системы и принципы их работы // Труды Северо-Кавказского филиала Московского технического университета связи и информатики. 2019. № 2. С. 88-94.
21. Шейнов А.И., Пастухова О.Н. Современные способы выявления мошеннических транзакций в сети интернет // Вестник Тульского филиала Финуниверситета. 2019. № 1-2. С. 311-313.
22. Group-IB — одна из ведущих международных компаний по предотвращению и расследованию киберпреступлений и мошенничеств с использованием высоких технологий. – Режим доступа. – URL: https://www.group-ib.ru/about.html
23. Аналитический комплекс «FRAUD RECORDER» // Свидетельство о регистрации программы для ЭВМ RU 2018617465, 25.06.2018. Заявка № 2018613591 от 04.04.2018.
24. Глобальное исследование по вопросам мошенничества в банковской сфере. – М.: ООО «КПМГ Налоги и консультирование». 2019. 28°с.
25. Программа для ЭВМ система поиска аномалий и построения объектных траекторий в транзакционных данных (СПАПОТ) // Свидетельство о регистрации программы для ЭВМ RU 2020613918, 24.03.2020. Заявка № 2019666822 от 17.12.2019.
26. Расследования высокотехнологичных преступлений Борьба с компьютерными, финансовыми, корпоративными преступлениями по всему миру. – Режим доступа. – URL: https://www.group-ib.ru/
27. Гайкович Ю.В, Першин А.С. Безопасность электронных банковских систем. // М: Единая Европа, 1994 г.
28. Линьков И.И. и др. Информационные подразделения в коммерческих структурах: как выжить и преуспеть. // М: НИТ, 1998 г.
29. Панкратов Ф.Г. Коммерческая деятельность : учеб.для вузов / Ф. Г. Панкратов. — Изд. 8-е, перераб. и доп. // М. : Дашков и Ко, 2015. — 502 с.
30. Петренко С.А. и Курбатов В.А. Политики безопасности компании при работе в интернет // ДМК Пресс, 2011.
31. Запечников С.В., Милославская Н.Г., Толстой А.И., Ушаков Д.В. Информационная безопасность открытых систем. В 2 томах. Том 1. Угрозы, уязвимости, атаки и подходы к защите / М:Гостехиздат, 2016

---

1   2   3