Проект - Платежные карты: Бизнес-энциклопедия

Читать онлайн «Платежные карты: Бизнес-энциклопедия». Страница 81

Автор Проект

С точки зрения эмиссии для использования протокола только в платежной системе MasterCard зарегистрировалось более 20,5 млн держателей карт MasterCard и Maestro. Конечно, это очень малая доля (несколько процентов) держателей карт с точки зрения общего количества карт этой платежной системы. Можно говорить, что именно медленное внедрение эмиссионной части протокола является главной причиной повышения безопасности операций ЭК.

В то же время по данным MasterCard в июле 2007 г. примерно 22 % всех операций ЭК в Европе производилось в магазинах, поддерживающих 3D Secure. При этом, в примерно 6 % всех операций 3D Secure поддерживался как со стороны торговых предприятий и обслуживающих банков, так и со стороны эмитентов карт.

Многие обслуживающие банки (онлайновые магазины) применяют в своих системах дополнительные проверки при обработке транзакций ЭК. К таким проверкам относятся:

• проверка адреса держателя карты (address verification system); предоставление для проверки эмитенту значений CVV2/CVC2;

• проверка количества транзакций, выполненных с некоторого IP-адреса (IP address frequency check);

• контроль количества транзакций, выполненных по карте в течение определенного промежутка времени (card number frequency check);

• проверка на совпадение страны адреса доставки товаров со страной, резидентом которой является банк, выдавший карточку (country match). Страна, резидентом которой является банк, определяется по значению идентификационного номера банка (bank identification number, или BIN);

• проверка IP-адреса (или сетки адресов), с которого была инициирована транзакция, на предмет его нахождения в черном списке (block IP address);

• проверка местоположения держателя карты (по IP-адресу его Интернет-провайдера) с географией доставки товаров (geolocation);

• отсев карт по некоторым ВШам банков (block bank BINs);

• отсев транзакций, поступающих с анонимных прокси-серверов (block proxy);

• отсев транзакций, при совершении которых были указаны адреса электронной почты из определенных доменов, например доменов, которые предлагают услуги бесплатной электронной почты (block proxy);

• проверка номера карты на ее присутствие в черном списке (negative database);

• использование открытых ресурсов, хранящих черные списки реквизитов мошеннических карт (например, CyberSource Negative Database and Scoring System, SharedGlobal Negative Database and Scoring System), а также осуществляющих аутентификацию держателя карты по номеру его телефона (MyVirtualCard).

Первые две проверки из приведенного выше списка рекомендуются платежными системами. Так VISA считает, что использование проверки CVV2 уменьшает вероятность фрода более чем на 60 %. Сегодня платежные системы предпринимают шаги к тому, чтобы обязать эмитентов проверять значения CVC2/CVV2, полученные из авторизационных запросов, в своих процессинговых системах, а высокорискованные торговые предприятия (например, онлайновые казино) вставлять в авторизационные запросы значения этих криптовеличин.

Исследования компании ClearCommerce (США) относительно оценки эффективности использования системы AVS показывают, что только 40 % транзакций успешно проходят эту проверку при том, что доля мошеннических среди них менее процента. С другой стороны, при использовании AVS 35 % мошеннических операций успешно преодолевают эту защиту.

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

• клиент впервые обслуживается в магазине;

• размер операции выше обычного для магазина значения;

• заказ состоит из большого количества одинаковых предметов;

• транзакции выполняются по картам с похожими номерами;

• адрес доставки заказа один и тот же для покупок, совершенных по разным картам;

• несколько транзакций по одной карте в течение короткого интервала времени;

• несколько транзакций, выполненных по различным картам с одним адресом доставки выписок (billing address), но разными адресами доставки товаров;

• транзакция, которую клиент хочет оплатить более чем одной картой.

У магазина (особенно MO (TO) — магазина) могут быть и другие причины для сомнения — нерешительность держателя карты в предоставлении персональных данных, требование к срочности выполнения заказа, странный адрес доставки, незаинтересованность клиента в свойствах товара (например, в цвете) и т. д.

Другой ранее упоминавшийся аспект проблемы мошенничества для CNP-транзакций — кража данных о реквизитах карт с серверов главным образом онлайновых магазинов. Несмотря на запрет платежных систем, обслуживающие банки и торговые предприятия хранят в своих системах значения CVC2/CVV2, данные магнитной полосы карты, адреса, используемые в AVS, зашифрованные PIN-блоки. Онлайновые магазины оставляют в своих БД доступные им данные: номер карты, срок ее действия, иногда CVV2/CVC2 и адрес, используемый в системе AVS. Исследования, выполненные Visa USA, показали, что в США 37 % торговых предприятий, несмотря на запреты платежных систем, продолжают хранить в своих системах информацию по картам.

В результате при взломе сайтов онлайновых магазинов происходит компрометация данных карт различных эмитентов. Самыми показательными является случаи взлома сервера TJX и БД процессора CardSystems Solutions, в результате которых были потенциально скомпрометированы соответственно 45,7 и 40,0 млн карт.

Для повышения уровня защиты информации ведущие платежные системы в течение нескольких последних лет требовали от своих банков участия в программах VISA account information security и MasterCard site data protection. Эти программы требуют от банков контроля обслуживаемых ими онлайновых магазинов с точки зрения выполнения ряда требований безопасности. К таким требованиям безопасности относятся:

• поддержка на сервере торгового предприятия средств защиты сетевого доступа (firewall);

• шифрование конфиденциальных данных при их хранении и передаче;

• использование актуальных антивирусных программ;

• своевременное применение «заплат безопасности» в используемом программном обеспечении;

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

• выполнение постоянных аудитов систем безопасности онлайновых магазинов.

В конце 2004 г. в основу программ защиты данных двух ведущих платежных систем был положен стандарт Plastic card industry data security standard (PCI DSS). Стандарт включает в себя 12 требований верхнего уровня, которые должны удовлетворяться информационными системами любого (в том числе онлайнового) магазина или третьестороннего процессора. Эти требования перечислены ниже:

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

2. Нельзя использовать значения по умолчанию паролей и других параметров безопасности в используемых магазином системах. Как пример для иллюстрации, использование дефолтных значений параметров протокола WEP, применяемого для обеспечения безопасности беспроводной радиосвязи Wi-Fi при использовании стандарта IEEE 802.11b приводит к тому, что большинство устройств этого стандарта на данный момент не поддерживают необходимого уровня безопасности.

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

4. Передаваемые по сети данные держателя карты должны быть надежно зашифрованы (допускается использование симметричных алгоритмов 3DES с ключом не менее 112 битов, AES с длиной ключа 256 битов и асимметричного алгоритма RSA с длиной ключа 1024 битов).

5. Необходимо использовать и регулярно обновлять антивирусное программное обеспечение.

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

7. Использовать ограничение доступа сотрудников торгового предприятия только к функциям и информации, необходимым им по роду деятельности.

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