Безопасность карточного бизнеса : бизнес-энциклопедия

В данном разделе описаны стандарты платежных систем, определяющие требования к информационной безопасности, а также политика платежных систем VISA и MasterCard в части контроля и применения. Подробнее всего будет рассмотрен основной стандарт — Payment Card Industry Data Security Standard (PCI DSS), также будут затронуты вопросы смежных стандартов, таких как PA DSS и PCI PED.

Стандарт PCI DSS

В последние годы по всему миру участились случаи взлома банковских информационных систем, а также факты мошенничества и кражи данных держателей карт. Подобная нездоровая тенденция послужила одной из главных причин, побудившей международные платежные системы объединить свои усилия и принять дополнительные меры для защиты своих клиентов. С 2001 г. платежные системы начали разрабатывать собственные программы обеспечения информационной безопасности для снижения рисков мошенничества — в VISA это были программы Cardholder Information Security Program (CISP) и Account Information Security (AIS), в MasterCard была разработана программа Site Data Protection (SDP). В 2004 г. был разработан единый набор требований к безопасности данных — Payment Card Industry Data Security Standard 1.0, объединивший в себе требования ряда программ по безопасности платежных систем VISA Int., MasterCard, American Express, Discover Card и JCB.

Впоследствии, в сентябре 2006 г., для развития и продвижения стандарта PCI DSS, был создан специальный Совет по безопасности — PCI Security Standards Council. Основными функциями Совета по безопасности являются разработка и публикация стандартов PCI и всей сопутствующей документации, определение требований к компаниям, планирующим получить сертификацию для проведения аудитов по PCI DSS («QSA») и сканирований («ASV»), осуществление непосредственно самой сертификации, проведение обучающих тренингов для будущих QSA-аудиторов, а также осуществление контроля качества проведенных аудиторами работ. Официальным источником информации о стандартах PCI является сайт Совета по безопасности[66], там можно найти:

• ответы на частые вопросы — FAQ;

• описание рисков, связанных с каждым требованием стандарта — Navigating PCI DSS Document;

• дополнительные материалы и рекомендации Совета по выполнению требований стандарта PCI DSS;

• тексты стандартов PCI DSS, PA DSS и PCI PED на различных языках[67].

В свою очередь международные платежные системы принимают отчетность по результатам аудитов и оценивают работу QSA.

Обновленная версия стандарта PCI DSS 1.1 вышла в сентябре 2006 г., в ноябре 2008 г. вышла версия 1.2 и текущая версия 2.0 на момент написания книги была принята в ноябре 2010 г. Несмотря на большое количество различных версий, по сути набор требований не претерпел существенных изменений, новые версии стандарта в основном содержали уточнение требований и исправление ошибок.

Действие стандарта PCI DSS распространяется на все торгово-сервисные предприятия (merchants) и поставщиков услуг (service providers), работающих с международными платежными системами, т. е. на всех тех, кто передает, обрабатывает и хранит данные держателей карт. В табл. 2.1 проиллюстрированы различные типы данных и требования к ним, которые выдвигает PCI DSS.

Также в зависимости от количества обрабатываемых транзакций каждой платежной системой компании присваивается определенный уровень с соответствующим набором требований, которые должны выполняться в обязательном порядке. Это может быть (1) ежегодное прохождение аудита, (2) ежеквартальные сканирования сети или (3) ежегодное заполнение листа самооценки (Self Assessment Questionnaire — специальная анкета, разработанная PCI SSC для самооценки компаний).

Требования Стандарта безопасности данных платежных приложений (PA DSS) являются производными от требований Стандарта безопасности данных индустрии платежных карт (PCI DSS) и Процедур аудита безопасности PCI DSS (PCI DSS Security Audit Procedures). Эти документы, с которыми можно ознакомиться на сайте PC PCI, содержат подробное описание требований безопасности данных, которые торгово-сервисные предприятия и сервис-провайдеры должны соблюдать для соответствия стандарту PCI DSS (следовательно, какое приложение платежной системы необходимо использовать для обеспечения соответствия этому стандарту)[68].

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

Ниже приведены несколько способов использования приложений платежных систем, при которых требования стандарта PCI DSS нарушаются:

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

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

• использование производителями незащищенных методов подключения к этим приложениям для технической поддержки клиента.

При использовании защищенных приложений платежных систем в среде, соответствующей требованиям стандарта PCI DSS, уменьшается вероятность нарушения безопасности, приводящая к компрометации полных данных магнитной полосы, кодов проверки подлинности карты (CAV2, CID, CVC2, CVV2), ПИН-кодов и ПИН-блоков и, в результате, — к осуществлению злоумышленниками мошеннических операций.

Все требования стандарта сгруппированы в 12 разделов, объединенных в 6 групп:

• построение и поддержание защищенной сети:

• требование 1: установка и администрирование конфигурации межсетевых экранов для защиты данных держателей карт;

• требование 2: не должны использоваться системные пароли и другие параметры безопасности, установленные производителем по умолчанию;

• защита данных держателей карт:

• требование 3: должна быть обеспечена защита данных держателей карт при хранении;

• требование 4: должно быть обеспечено шифрование передачи данных держателей карт по сетям общего пользования;

• реализация программы управления уязвимостями:

• требование 5: должно использоваться регулярно обновляемое антивирусное программное обеспечение;

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

• реализация мер по строгому контролю доступа:

• требование 7: доступ к данным держателей карт должен быть ограничен в соответствии со служебной необходимостью;

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

• требование 9: физический доступ к данным держателей карт должен быть ограничен;

• регулярный мониторинг и тестирование сетей:

• требование 10: должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт;

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

• поддержание политики информационной безопасности:

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

Каждое из 12 общих требований содержит ряд «подтребований» и процедур их проверки, которые, с одной стороны, обеспечивают (как минимум в теории) однообразие контроля требований аудиторам и, с другой стороны, часто детализируют само требование. Также для понимания сути требования и/или процедуры проверки бывает полезно учитывать, в какой группе находится данное требование. Описание требований приведено для версии стандарта PCI DSS 2.0.

Требование 1: установка и администрирование конфигурации межсетевых экранов для защиты данных держателей карт.

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

• сегментация сети на различные зоны безопасности и размещение серверов в них;

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

• настройка конкретных правил фильтрации трафика;

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

• настройка правил фильтрации трафика на мобильных компьютерах.

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

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

Требование 2: не должны использоваться системные пароли и другие параметры безопасности, установленные производителем по умолчанию.

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

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

• изменение параметров систем, установленных по умолчанию;

• разделение важных функций между различными серверами;

• удаление ненужного или неиспользуемого функционала;

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

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

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

Но в результате безопасность систем существенно возрастает, особенно в совокупности с правильно настроенным межсетевым экраном и вовремя устанавливаемыми обновлениями безопасности. По сути, реализация требований 1, 2 и 6 в полном объеме могли бы предотвратить более 90 % случившихся взломов систем с последующими утечками данных платежных карт.

Требование 3: должна быть обеспечена защита данных держателей карт при хранении.

Данное обобщенное требование содержит 15 требований и соответствующих им процедур оценки, определяющих, как необходимо обрабатывать, хранить и защищать непосредственно данные платежных карт (такие как PAN, TRACK, PINBLOCK и т. п.), в том числе:

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

• соблюдать политику по уничтожению номеров карт после истечения срока их обоснованного хранения;

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

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

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

• управлять криптографическими ключами, используемыми для шифрования данных при хранении.

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

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

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

• обновления базы данных, поскольку, например, в СУБД Oracle шифрование хорошо поддерживается начиная с 10-й версии;

• апгрейда оборудования на более производительное, поскольку шифрование требует больших аппаратных ресурсов;

• обеспечения шифрования резервных копий баз данных;

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

Требование 4: должно быть обеспечено шифрование передачи данных держателей карт по сетям общего пользования.

Данное обобщенное требование содержит 3 требования и 9 соответствующих им процедур оценки, регламентирующих вопросы шифрования данных платежных карт при передаче их по открытым каналам связи, с использованием программ мгновенного обмена сообщениями (таких как Skype, ICQ и т. п.) и через беспроводные сети.

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

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

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

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

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

Требование 6: должна обеспечиваться безопасность при разработке и поддержке систем и приложений.

Данное обобщенное требование содержит 24 требования и 32 соответствующие им процедуры оценки, регламентирующие вопросы поддержки и обновления систем и регламентирующие вопросы разработки.

Реализация данных требований обычно вызывает серьезные сложности по ряду причин:

1) в большинстве российских компаний обновления безопасности на внутренние серверы, особенно на базы данных, практически никогда не ставились, так как, по мнению администраторов, безопасность обеспечивают внешние межсетевые экраны, а любое обновление может нарушить работоспособность системы, что чревато намного большими проблемами, чем гипотетический взлом. К сожалению, эту логику администраторов вполне понимают и злоумышленники. И, как правило, очень успешно используют уязвимость внутренних серверов для получения доступа к данным пластиковых карт;

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

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

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

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

Требование 7: доступ к данным держателей карт должен быть ограничен в соответствии со служебной необходимостью.

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

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

Требование 8: каждому лицу, имеющему доступ к вычислительным ресурсам, должен быть назначен уникальный идентификатор.

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

• длине, сложности и частоте смены паролей;

• использованию двухфакторной аутентификации при удаленном доступе;

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

• хранению паролей в системах в нечитаемом виде;

• удалению неиспользуемых учетных записей;

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

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

Требование 9: физический доступ к данным держателей карт должен быть ограничен.

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

• систем видеонаблюдения и контроля доступа в помещения;

• визуальной идентификации посетителей;

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

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

Обычно к моменту принятия решения о внедрении стандарта PCI DSS большинство требований данного раздела в банковской организации уже выполняется. Особенно в случае, если банк занимается выпуском платежных карт самостоятельно — ведь для выпуска платежных карт предъявлены намного более серьезные требования по физической защите помещений. Вместе с требованием 5 (антивирусная защита) это требование является наиболее простым и понятным в реализации. Особенно если сравнивать его с требованием 3 (защита данных платежных карт) и требованием 10 (протоколирование и мониторинг доступа).

Требование 10: должен отслеживаться и контролироваться любой доступ к сетевым ресурсам и данным держателей карт.

Данное обобщенное требование содержит 27 требований и 29 соответствующих им процедур оценки, регламентирующих вопросы протоколирования и мониторинга событий, включая особенности:

• перечня и состава протоколируемых событий;

• удаленного хранения и защиты собранных журналов аудита;

• синхронизации времени между источниками событий и системой мониторинга;

• периода хранения журналов аудита.

Практика показывает, что одна из самых серьезных проблем на пути к соответствию PCI DSS — организация процесса мониторинга событий ИБ. C точки зрения стандарта организовать процесс можно различными способами: централизованно/децентрализованно, средствами автоматизации или без оных и т. п. Для обычного российского банка, имеющего собственный процессинг, организация мониторинга событий информационной безопасности могла бы выглядеть так:

• сбор событий автоматизирован;

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

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

Необходимо отметить важные особенности системы мониторинга событий ИБ применительно к задачам обеспечения и поддержания соответствия стандарту.

1. В систему мониторинга должны собираться события ИБ от всех типов ресурсов в области действия стандарта:

• операционных систем серверов;

• СУБД;

• сетевое оборудование;

• веб-серверы (если используются для обработки карт);

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

2. Настройки протоколирования данных ресурсов должны обеспечивать регистрацию (а система мониторинга, в свою очередь, — сбор, обработку и хранение) всех типов событий, приведенных в п. 10.2.1- 10.2.7 стандарта PCI DSS (если имеют смысл для данного типа ресурса), а именно:

• доступ к данным платежных карт (специфично для каждой из форм хранения данных — либо файлы, либо объекты базы данных);

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

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

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

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

• межсетевые экраны;

• IDS/IPS;

• средства антивирусной защиты;

• средства контроля целостности и др.

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

Требование 11: должно выполняться регулярное тестирование систем и процессов обеспечения безопасности.

Данное обобщенное требование содержит 9 требований и 23 соответствующих им процедуры оценки, регламентирующие аспекты периодического тестирования защищенности и частично вопросы обнаружения потенциальных несанкционированных вторжений/изменений в системах, в частности:

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

платежных систем и расчетов

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

• выявление несанкционированных беспроводных точек доступа;

• выявление несанкционированной активности в сети и/или изменения в файловых системах серверов;

• проведение ежегодных (или при изменении конфигурации сети или защищаемых серверов) внутренних и внешних тестов на проникновение.

Особенностью выполнения этих требований является то, что банку недостаточно просто провести сканирование или заказать тест на проникновение. Требование считается выполненным только в том случае, если в ходе тестирования/сканирования не было обнаружено серьезных уязвимостей. И при этом были протестированы все серверы/устройства и службы, которые входят в область применения стандарта. Более того, к моменту ежегодной проверки нужно показать, что на протяжении всего прошлого года своевременно проводились сканирования и оперативно устранялись уязвимости (в случае их наличия). Внутренние сканирования и тесты на проникновения могут проводиться любыми квалифицированными сотрудниками — как изнутри компании, так и приглашенными извне, тогда как внешнее сканирование должно проводиться сертифицированной компанией, имеющей статус Approved Scanning Vendor (ASV)[69].

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

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

• наличие политики безопасности и процедур, описывающих типовые операции обеспечения защиты;

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

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

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

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

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

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

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

Применение компенсационных мер

Важной особенностью, необходимой для применения стандарта, является понимание различий между выполнением требований стандарта PCI DSS и подтверждением выполнения этих требований.

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

При этом сам стандарт остается применимым. И вопросы, связанные, например, с контролем физического доступа к POS-терминалу, должны быть решены.

Итак, примем как факт, что если номера карт обращаются в системе — применимые требования PCI DSS нужно выполнять.

Теперь обратимся к требованиям платежных систем (в первую очередь VISA и MasterCard), ведь это именно они определяют, что компании должны делать, чтобы с ними работать.

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

У каждой платежной системы есть своя программа: для VISA — это Account Information Security (AIS) Programme[70], для MasterCard — это Site Data Protection (SDP) Program[71].

Программы немного различаются, но очевиден единый подход к оценке риска — чем больше данных платежных карт проходит через организацию, тем более жесткие требования к ее проверке на соответствие стандарту. При этом максимальный уровень проверки — это проведение ежегодного аудита с привлечением сертифицированного аудитора QSA, а также проведение ежеквартальных сканирований с привлечением сертифицированной компании ASV. Минимальный уровень проверки — это самостоятельное заполнение опросного листа или даже (в случае с MasterCard для торгово-сервисных организаций 3-го и 4-го уровней) отсутствие каких-либо требований (их определяет банк-эквайрер).

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

Итак, необходимо начать с области применения стандарта PCI DSS. Исходно стандарт PCI DSS разрабатывался в основном для крупных торгово-сервисных организаций (миллионы транзакций в год) и сервис-провайдеров и нацелен на снижение рисков утечки данных «чужих» платежных карт в рамках в основном процессов авторизации. Несмотря на это обстоятельство его требования должны выполнять любые компании, в которых происходит обработка, хранение или передача как минимум PAN.

Данную позицию Совет по безопасности PCI (PCI SSC) изложил в своем FAQ.

Сложности при выполнении требований стандарта испытывают банки, которые занимаются выпуском платежных карт, их системы, обеспечивающие выпуск карт (особенно в случае, когда они интегрированы с АБС). В большинстве случаев системы разрабатывались без оглядки на требования PCI DSS (такие, как шифрование PAN, протоколирование доступа к PAN и т. п.). Доработка существующих систем (или замена, что может быть даже дешевле) под выполнение требований по безопасности — задача затратная и по времени, и по ресурсам. И для бизнеса не совсем очевидная.

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

Рассмотрим требования наиболее распространенных платежных систем VISA и MasterCard к области проверки выполнения требований стандарта PCI DSS в регионе CEMEA, которые они доводят до аудиторов QSA:

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

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

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

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

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

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

Особенно интересен тот факт, что не требуется проверять и сети банкоматов (что выглядит странным, так как они участвуют в авторизации непосредственным образом). Стоит заметить, что с учетом опыта последних инцидентов с вирусами на банкоматах МПС (в частности, VISA) рекомендует для снижения подобных рисков реализовать для банкоматов те же защитные меры, что вошли в стандарт PCI DSS, но это именно рекомендации. Члены платежной системы вправе рассмотреть их эффективность, вправе даже привлечь QSA-аудиторов для оценки их выполнения. Но невыполнение банками ряда требований PCI DSS на банкоматах не может быть классифицировано аудиторами как несоответствие стандарту PCI DSS, препятствующее получению сертификата соответствия в рамках определенной самими платежными системами области проведения сертификационного аудита PCI Validation Scope (для сравнения — на Западе аудиторы проверяют и банкоматы тоже).

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

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

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

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

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

1. Опросные листы самооценки — бесплатный конфиденциальный инструмент, который может использоваться для оценки соответствия платежных систем и расчетов стандарту безопасности данных PCI. Опросный лист разбит на шесть разделов, каждый ориентирован на отдельную область безопасности, основанную на требованиях, включенных в PCI DSS. Участники — торгово-сервисные предприятия и сервис-провайдеры — обязаны заполнить все пункты каждого раздела, чтобы определить соответствие.

2. Процедуры сканирования безопасности описывают директивы для проведения сканирования безопасности сети в соответствии с PCI DSS.

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

3. Процедуры аудита безопасности — документ, используемый для проверки соответствия организаций, которые должны пройти onsite-аудит.

Самооценка. Заполнение листа самооценки может самостоятельно выполняться любой организацией, заинтересованной в соответствии стандарту безопасности данных PCI.

Сканирование и onsite-аудит. Сканирование сети и onsite-аудит должны проводиться квалифицированным аудитором систем безопасности (Qualified Security Assessor).

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

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

Дополнительно эквайреры должны предоставить VISA отчеты о соответствии по своим ТСП уровней 1, 2 и 3 как минимум дважды в год. VISA оставляет за собой право запросить у эквайрера отправку документации о проверке соответствия по конкретному ТСП.

Дата 30 сентября 2009 г. была определена VISA Inc. как крайний срок хранения запрещенных конфиденциальных данных для ТСП уровня 1 и 2. После этой даты платежная система имеет право потребовать от эквайреров подтверждения того, что ТСП уровня 1 и 2 не хранят конфиденциальные данные (такие как данные магнитной полосы, треки, CVV2 или данные PIN) после авторизации транзакции, что является нарушением правил VISA. В отношении эквайреров, не предоставивших МПС до указанной выше даты (30 сентября 2009 г.) форму аттестата соответствия (Attestation of Compliance Form), подтверждающую, что все ТСП уровней 1 и 2 не хранят запрещенных конфиденциальных данных, VISA Inc. имеет право применить соответствующие меры по контролю рисков, вплоть до наложения штрафов. При этом оговаривается, что эта дата (30 сентября 2009 г.) не превалирует над более ранними сроками хранения конфиденциальных данных, определенными в конкретных регионах и соответствующими принудительными программами, установленными ранее (табл. 2.3).

Крайний срок проведения аудита соответствия стандарту PCI DSS для ТСП уровня 1 — 30 сентября 2010 г. К этой дате VISA Inc. требовала от эквайреров предоставить форму аттестата соответствия (Attestation of Compliance Form) по каждому ТСП уровня 1, показывающую, что каждое ТСП прошло успешный аудит соответствия PCI DSS. В отношении эквайреров, не предоставивших платежной системе форму аттестата соответствия, подтверждающую, что каждое ТСП уровня 1 прошло проверку соответствия PCI DSS, после этой даты VISA имеет право применить соответствующие меры по контролю рисков, вплоть до наложения штрафов. При этом указанная дата (30 сентября 2010 г.) не превалирует над более ранними сроками хранения конфиденциальных данных, определенными в конкретных регионах и соответствующими принудительными программами, уже введенными в действие.

Сервис-провайдеры второго уровня не включаются в список PCI DSS Compliant Service Providers, доступный на сайте VISA. Для включения в данный список сервис-провайдер второго уровня должен пройти процедуры проверки соответствия для первого уровня.

Начиная с 1 февраля 2009 г. VISA требует от сервис-провайдеров уровня 1 отправки Attestation of Compliance Form (аттестат соответствия) и раздела «Executive Summary» (результаты проведенного аудита) отчета о соответствии (Report on Compliance, ROC). Сервис-провайдеры уровня 2 отправляют заполненный самоопросник (Self-Assessment Questionnaire, SAQ) версии D. VISA не рассматривает содержимое самоопросника, так как за точность заполнения самоопросника SAQ отвечают эмитенты и эквайреры.

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

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

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

Программа MasterCard SDP была разработана, чтобы помочь торгово-сервисным предприятиям (ТСП), сервис-провайдерам — сторонним процессингам (Third Party Processors, TPPs) и организациям хранения данных (Data Storage Entities, DSEs) — упредительно обеспечить собственную защиту и всей платежной системы в целом от угроз компрометации.

Ключевой целью реализации программы SDP является обеспечение безопасного хранения ТСП и сервис-провайдерами данных учетных записей MasterCard в соответствии со стандартом безопасности данных в индустрии платежных карт (PCI DSS).

ТСП и сервис-провайдерам важно понимать свое положение (классифицировать) в программе MasterCard SDP для определения обязательных процедур подтверждения соответствия. Классификация организаций по уровням приведена в табл. 2.4, сервис-провайдеров — в табл. 2.5.

MasterCard оказывает содействие эквайрерам по программе SDP для поддержания безопасной инфраструктуры с торгово-сервисными предприятиями. Эквайеры сами по себе не обязаны проходить процедуры соответствия SDP, но они должны управлять этим процессом для своих ТСП.

Эквайреры должны ежеквартально высылать заполненную форму SDP Acquirer Submission and Compliance Status Form[72]. В нее включен список всех ТСП и сервис-провайдеров (хранящих данные для указанных ТСП), которые должны соответствовать PCI DSS в течение каждого периода действия положения о программе SDP. Для каждого ТСП эквайреры должны предоставить:

• название ТСП;

• идентификационный номер ТСП (Merchant ID);

• код категории ТСП (Merchant category code, MCC);

• уровень ТСП (см. выше табл. 2.4);

• статус соответствия стандарту;

• название каждого сервис-провайдера, хранящего учетные данные MasterCard, работающего с данным ТСП;

• количество проведенных транзакций ТСП за предыдущий отчетный период (12 месяцев).

1. Развернуть программу безопасности SDP для всех ТСП в соответствии с расписанием внедрения SDP.

2. Убедиться, что ТСП соответствуют PCI DSS путем использования надлежащих инструментов проверки соответствия, включающие onsite-аудиты безопасности, заполнение самоопросников (the self-assessment questionnaire) и сканирования сети.

3. Зарегистрировать ТСП, как только они докажут свое соответствие требованиям положения о программе SDP. Данный процесс регистрации осуществляется непрерывно в течение года с помощью программы регистрации MasterCard (MasterCard Registration Program, MRP). MasterCard отмечает, что регистрация ТСП, соответствующих SDP, бесплатна в программе регистрации MRP, доступной посредством MasterCard OnLine.

В конце 2010 г. по заказу Cisco аналитическая компания Insight-Express опросила 500 американских руководителей, принимающих решения в области информационных технологий, чтобы выяснить их отношение к стандарту PCI DSS через пять лет после его разработки и в момент выхода его новой, второй версии.

В опросе приняли участие ИТ-руководители, отвечающие за соблюдение PCI в организациях сферы образования, финансовых услуг, государственного управления, здравоохранения и розничной торговли США. Исследователи хотели оценить их отношение к стандарту PCI DSS, измерить расходы на его внедрение и выявить проблемы, связанные с соблюдением этих нормативных требований, а также оценить распространение определенных технологий, чтобы лучше понять, чем организации руководствуются при выполнении спецификации PCI DSS. Выяснилось следующее:

• 70 % процентов опрошенных считают, что соблюдение стандарта PCI DSS делает их организации более защищенными;

• 87 % процентов опрошенных полагают, что требования стандарта PCI DSS необходимы для защиты данных держателей платежных карт;

• из всех отраслей лучше всех выполняют требования PCI DSS предприятия розничной торговли и финансовые организации; розничная торговля самым серьезным образом отнеслась к внедрению и реализации этого стандарта;

• 67 % процентов опрошенных ожидают, что в течение ближайшего года их расходы на соблюдение стандарта PCI DSS будут возрастать; это значит, что руководители компаний и члены советов директоров считают PCI DSS весьма важной инициативой;

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

Отвечая на вопрос о проблемах соблюдения спецификаций PCI DSS, респонденты чаще всего упоминали необходимость обучения сотрудников правильному обращению с данными держателей платежных карт. По мнению 43 % опрошенных, в этой области существуют проблемы. Кроме того, 32 % упомянули о необходимости обновления устаревших систем.

По мнению респондентов, из 12 требований PCI DSS труднее всего соблюдать требования к отслеживанию и мониторингу всех случаев доступа к сетевым ресурсам и пользовательским данным (37 %), разработке и поддержке безопасных систем и приложений (32 %) и защите хранимых данных держателей карт (30 %).

Еще один интересный отчет Global Security Report 2011 подготовила компания Trustwave, базируясь на данных более чем 200 расследований случаев компрометации данных и около 2300 проведенных тестирований на проникновение (имитаций взлома системы) за 2010 г. по всему миру (но основная масса случаев была зафиксирована в Северной Америке).

Как и раньше, данные платежных карт были основной целью злоумышленников в 85 % расследованных случаев. В 8 % случаев целью была конфиденциальная информация компании и около 3 % — сведения, составляющие коммерческую тайну.

В целом выводы в отчете приводятся следующие:

• более 95 % скомпрометированных организаций не выполняли требования PCI DSS в полном объеме;

• почти 98 % организаций нарушали требования, относящиеся к межсетевому экранированию;

• 60 % случаев компрометации было выявлено в ходе ежегодного аудита по требованиям PCI DSS.

Факты компрометации сами компании выявили не более чем в 20 % случаев, при этом информация о факте компрометации была опубликована в 13 % случаев, а правоохранительные органы привлекались в 7 % случаев.

Среднее время между фактом компрометации и его обнаружением составило 156,5 дня, в случае если выявление происходило в рамках ежегодного аудита, и 87,5 дня, 51,5 дня и 28 дней, в случае если источником обнаружения были публикация в прессе, расследование правоохранительных органов и самостоятельное обнаружение соответственно.

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

Прочие стандарты PCI

Организации индустрии платежных карт разрабатывают общий стандарт, регулирующий в том числе аспекты безопасности устройств ввода ПИН-кодов (PIN entry devices, PEDs). Требования к таким устройствам регламентируют методологию тестирования устройств и процесс утверждения сертифицированных устройств и включают требования по защите ПИН-кодов.

Задача PCI PED — удостовериться в том, что устройство, принимающее ПИН-код, обеспечивает защиту чувствительной информации, такой как резидентные ключи, ПИН владельца пластиковой карты и др.

Цель требований заключается в обеспечении единого, последовательного и точного стандарта для всех устройств ввода ПИН-кодов по всему миру.

Программа тестирования и утверждения устройств ввода ПИН-кодов отражает стандартный набор:

• требования безопасности к устройствам;

• методологию тестирования;

• процесс сертификации и утверждения.

Требования Стандарта безопасности данных платежных приложений (PA DSS) являются производными от требований Стандарта безопасности данных индустрии платежных карт (PCI DSS) и Процедур аудита безопасности PCI DSS (PCI DSS Security Audit Procedures). Эти документы, с которыми можно ознакомиться на сайте[75], содержат подробное описание требований безопасности данных, которые торгово-сервисные предприятия и сервис-провайдеры должны соблюдать для соответствия стандарту PCI DSS (следовательно, какое приложение платежной системы необходимо использовать для обеспечения соответствия этому стандарту).

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

Ниже приведены несколько способов использования приложений платежных систем, при которых требования стандарта PCI DSS нарушаются:

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

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

• использование производителями незащищенных методов подключения к этим приложениям для технической поддержки клиента.

При использовании в среде, соответствующей требованиям стандарта PCI DSS, защищенных приложений платежных систем уменьшается вероятность нарушения безопасности, приводящая к компрометации полных данных магнитной полосы, кодов проверки подлинности карты (CAV2, CID, CVC2, CVV2), ПИН-кодов и ПИН-блоков и, в результате, к осуществлению хакерами мошеннических операций.

PCI DSS и российская действительность

Внедрение стандарта PCI DSS в России идет непросто. Во многих банках оно находится в активной фазе[76], но ряд крупных банков еще даже не начинали активных действий по внедрению стандарта. Почему же сложилась такая ситуация — ведь стандарт является обязательным для российских компаний аж с далекого 2007 г.?

Автору с 2007 по 2011 г. удалось понаблюдать (с позиции сертифицированного аудитора QSA), как трудно происходит проникновение стандарта в умы и бюджеты банков и сервисных провайдеров в России и странах СНГ. Основных причин возникающих проблем, по мнению автора, несколько.

1. Относительно низкий уровень обеспечения информационной безопасности и управления ИБ в большинстве российских банков по сравнению с банками Западной Европы и США.

На момент сдачи книги в печать.

Исторически сложилось так, что подавляющее большинство российских банков строили свои системы обеспечения и управления ИБ, ориентируясь в первую очередь на нормативные документы и лучшие практики ФСТЭК, ФСБ, которые были разработаны без учета современного уровня развития информационных технологий и повсеместного проникновения Интернета и мобильной связи. При этом часть современных угроз безопасности остаются «незакрытыми».

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

2. Многократный перенос сроков внедрения стандарта и отсутствие фактов наложения штрафов за несоответствие стандарту PCI DSS для российских банков в совокупности с небезызвестным российским менталитетом.

Совершенно понятна позиция платежных систем, заключающаяся в том, чтобы «не рубить сук, на котором сидишь», т. е не трогать банки, приносящие хороший доход платежной системе. Очевидно, это понимают и банки, позиция руководства которых в этом вопросе может быть довольно резка. «Пусть попробуют штрафануть — уйдем в другую платежную систему», «Пока кого-нибудь из топ 20 не оштрафуют, мы на это деньги тратить не будем», «Да мы входим в правление платежной системы, пусть попробуют нам что-нибудь сказать», «Сроки уже три раза переносили, так и еще перенесут скорее всего» — это реальные высказывания серьезных банков образца 2007–2008 гг. Ближе к 2011 г. большинство банков смирились с необходимостью рано или поздно соответствовать стандарту и начали движение в сторону его изучения и выполнения требований.

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

3. Относительно низкий уровень мошенничества в российском сегменте сети Интернет и отсутствие публичных серьезных утечек информации в процессинговых центрах российских банков.

Ни для кого уже не секрет, что существенную часть подпольного карточного бизнеса контролируют выходцы из России и стран СНГ, в первую очередь Украины. До недавнего времени существовало негласное правило не трогать банки в своем регионе — в основном не из патриотических, конечно, убеждений, а исходя из вопросов личной безопасности — ведь достать же могут и правоохранительные органы, и службы безопасности банков, что может быть хуже. Тем более когда через Интернет легко получить доступ к базам данных мерчантов и процессинговых компаний США, Европы. Карточные лимиты у клиентов западных банков побольше, а уровень взаимодействия российских правоохранительных органов с зарубежными далек от совершенства. В результате мошенничество по картам на территории России в основном сводится к скиммингу в банкоматах и получению наличных с использованием поддельных карт. А если и взломают какой процессинг — так не для получения данных платежных карт, а скорее для устрашения и передела нелегального рынка.

4. Относительно низкая степень развития российского рынка эквайринга в целом по сравнению с Европой и США.

Количество транзакций по картам в России в несколько раз меньше, чем в Европе, и на порядки меньше, чем в США. Наши крупнейшие торговые сети только доходят до уровня 6 млн транзакций в год и могут быть посчитаны по пальцам одной руки, тогда как безопасность мерчантов 1 уровня (выше 6 млн транзакций в год) в США, которых там насчитываются сотни, — основной приоритет последних четырех лет работы консула по безопасности США.

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

С учетом всех обстоятельств какой ответ можно дать на главный вопрос: является ли стандарт PCI DSS панацеей от всех бед, связанных с мошенничеством, или, наоборот, отвлекает ресурсы компании и не дает ожидаемого эффекта? Мнения по данному вопросу у экспертов по безопасности и участников рынка различны, порой диаметрально противоположны.

Многие представители российского бизнеса считают внедрение стандарта бессмысленной тратой денег, навязанной международными платежными системами. Если банки готовы взять на себя риск, связанный с мошенничеством, считают они, то должны сами определять требования по безопасности. Заниматься этими вопросами серьезно стоит лишь тогда, когда потери от мошенничества составят ощутимый процент от оборота. У представителей западного бизнеса позиция гораздо более активная — они стараются сами войти в Совет по безопасности PCI (PCI SSC) и непосредственно участвовать в развитии стандарта и практике его применения. На текущий момент в Совет по безопасности PCI, помимо пяти платежных систем, входят более 1300 банков и торговых организаций со всего мира, но, к сожалению, российского бизнеса там пока еще незаметно.

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

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

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

Конечно, не может быть стопроцентной уверенности в том, что если бы требования стандарта выполнялись, то компрометации бы не произошло. Но ущерб как минимум был бы намного меньше, хотя бы в результате того, что в ходе мониторинга событий ИБ и/или регулярных проверок безопасности, предписанных стандартом, компрометация была бы обнаружена существенно быстрее. В реальности же среднее время обнаружения факта компрометации — более 6 месяцев после взлома, а инициатором расследования часто служат внешние источники, такие как платежные системы, обманутые клиенты или СМИ.

Переход на новые технологии авторизации (EMV, 3D Secure и т. п.) может существенно понизить уровень мошенничества по существующим схемам. Но вопросы безопасности инфраструктуры, обеспечивающей прохождение платежей, безопасности разрабатываемых прикладных приложений, разграничение доступа сотрудников, мониторинг и реагирование на инциденты ИБ и прочие вопросы информационной безопасности, изменение технологии авторизации решить не сможет, а как раз для этого и предназначен стандарт PCI DSS. Для переноса интересов преступности из сферы мошенничества с использованием пластиковых карт на другие способы незаконного получения и/или отмывания денег в особо крупных размерах необходимо одновременно и переходить на новые технологии авторизации, и защищать инфраструктуру путем внедрения стандарта PCI DSS, а также разрабатывать защищенные приложения в соответствии со стандартом PA DSS.

В 2010 г. компания Verizon Business опубликовала очередной отчет о компрометации данных «2010 Data Breach Investigations Report». В основу исследования, проведенного подразделением Verizon RISK Team совместно с United States Secret Service, легли данные за последние 6 лет о более чем 900 взломах различных автоматизированных систем и свыше 900 млн скомпрометированных элементов данных (compromised records).

Основные выводы данного исследования по фактам компрометации данных в 2009 г. следующие:

1) скомпрометированы 143 млн элементов данных;

2) подавляющее большинство (94 %) скомпрометированных данных относится к финансовому сектору, хотя на долю финансовых организаций приходится лишь 33 % от общего числа компаний, принявших участие в исследовании. Организованные преступные группы были задействованы в компрометации в 85 % всех данных;

3) в результате действий сторонних лиц взломы осуществлялись в 70 % случаев, внутренние нарушители были задействованы в 48 % инцидентов. Злоупотребление привилегиями было использовано в 48 % всех атак, взлом (hacking) применялся в 40 % случаев, вредоносное ПО — в 38 %;

4) почти все атаки на данные (98 %) осуществлялись на серверы, на серверы баз данных — 92 %;

5) сложность атак была невысокой в 85 % случаях, а 96 % атак могло быть предотвращено с помощью применения простых и средних по сложности мер защиты;

6) 79 % организаций, к которым применимы требования стандарта PCI DSS, участвовавшие в исследовании, не достигли соответствия его требованиям;

7) данные платежных карт скомпрометированы в 54 % инцидентов и составляют 83 % от общего числа скомпрометированных данных.

Результаты других исследований и проведенных расследований также не очень утешительны. Так, в 2005 г. в результате взлома процессингового центра Card Systems Solutions было скомпрометировано 40 млн платежных карт. Компания необоснованно хранила треки (данные с магнитных полос карт) и при этом не защищала их должным образом, в результате международные платежные системы VISA и Ameх отозвали свои лицензии. В 2007 г. хакеры похитили 45 млн записей с данными платежных карт в результате атаки на крупную розничную сеть TJX.

В 2008 г. был взломан RBS Worldpay, что привело к компрометации данных 1,5 млн держателей карт. А в 2009 г. злоумышленники получили доступ к более чем 100 млн платежных карт в результате взлома процессингового центра Heartland Payment Systems.

Безопасность платежных карт — два пути

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

1) замена уязвимых технологий более безопасными;

2) сохранение существующих уязвимых технологий и защита их дополнительными методами и системами.

Первый путь связан с миграцией на микропроцессорные карты стандарта EMV для предотвращения несанкционированного копирования (скимминга) магнитной полосы карты (защита от Counterfeit Fraud — 34 % всех потерь в мире за 2009 г.) и посредством внедрения более надежных систем аутентификации держателя карты при проведении операций без присутствия карты (противодействие Card Not Present Fraud — 41 % всех потерь в мире за 2009 г.), причем в последнем случае в ряде решений также может использоваться EMV-карта. Повсеместного перехода на микропроцессорные карты до сих пор не произошло, и хотя уже более 60 стран мира начали процесс миграции, США являются пока единственной страной G20 («Большая двадцатка» наиболее экономически развитых стран мира), официально даже не начавшей его.

К настоящему моменту отказ от использования микропроцессорных карт стоит США весьма дорого — так, потери от мошенничества с платежным картами в 2009 г. составили 6,89 млрд долл. США и к 2015 г. могут достигнуть 10 млрд долл. США. По некоторым оценкам стоимость принятия мер по каждому факту компрометации данных платежной карты в США составляет 202 долл. США, так что только в 2008 г. на устранение последствий атак был потрачен 1 трлн долл. США. По оценкам экспертов стоимость миграции на EMV для США составляет 8,6 млрд долл. США, т. е. вполне сопоставима с ежегодными потерями от мошенничества в 6,89 млрд долл. США! Тем не менее США, а вместе с ними и весь остальной мир по требованиям международных платежных систем пошли по второму пути.

Второй путь состоит, как мы уже определили выше, в защите существующих уязвимых технологий (прежде всего — платежных карт с магнитной полосой). Для разработки повышенных требований к обеспечению безопасности данных платежных карт в 2006 г. был создан специальный Совет стандартов безопасности индустрии платежных карт (Payment Card Industry Security Standards Council), в который вошли American Express, Discover Financial Services, JCB, MasterCard Worldwide, VISA International. Стандарт Payment Card Industry Data Security Standard (PCI DSS, в настоящий момент версия 2.0, далее — Стандарт) определяет требования безопасности для защиты информации, относящейся к платежной карте, и должен использоваться тогда, когда номер карты хранится, обрабатывается или передается.

Приведенные в Стандарте требования[77] призваны обеспечить безопасность данных платежных карт за счет повышения защищенности автоматизированных систем, в которых эти данные обрабатываются. Соответствие требованиям Стандарта должно означать, что система защищена и компрометация данных в ней произойти не может. Однако вышеназванные компании, в которых были скомпрометированы данные, — Card Systems Solutions, RBS WorldPay, Heartland Payment Systems, — до этого проходили аудит и получили статус соответствия Стандарту. Примечательно, что компании RBS WorldPay и Heartland Payment Systems в марте 2009 г. были исключены VISA из списка соответствующих стандарту, но сразу же заявили, что надеются вновь пройти сертификацию уже в апреле и мае 2009 г. соответственно, и достигли этого соответствия.

PCI DSS = безопасность платежных карт?

В связи с приведенными фактами возникает ряд вопросов. Во-первых, способен ли Стандарт обеспечить безопасность платежных карт?

Во-вторых, почему его внедрение не приводит к уменьшению числа компрометаций и объема скомпрометированных данных? Эти вопросы волнуют в настоящий момент всех специалистов по безопасности в отрасли, они же явились предметом особого рассмотрения в Комитете национальной безопасности палаты представителей США (House of Representatives Committee on Homeland Security) 31 марта 2009 г. в слушаниях на тему «Приводят ли Стандарты безопасности индустрии платежных карт к снижению киберпреступности?» («Do the PCI Standards Reduce Cybercrime?»).

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

Представители торговых компаний отметили, что следование требованиям Стандарта вовсе не приводит к состоянию уверенности в безопасности данных держателей карт, при этом реализация требований на практике связана с существенными затратами. А поскольку данные платежных карт все равно должны быть обработаны, т. е. как минимум в этот момент они представляются в незашифрованном виде, то компрометация остается возможной. Кроме того, торговые компании США расценивают Стандарт как некую «заплатку» (patch) безопасности, целью которого является перенос потерь на торговые предприятия. Член палаты представителей Иветта Кларк (Yvette Clark) заявила, что выполнение Стандарта не гарантирует безопасности, призвала к его изменению и переходу на новые защищенные технологии, например «ЧИП и ПИН» (Chip&PIN).

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

В результате слушаний были сделаны два основных вывода:

1. Стандарт не является достаточным для защиты данных держателей карт и следование его требованиям не обеспечивает в настоящий момент адекватной безопасности.

2. Стандарт скорее переносит бремя ответственности по мошенничеству, чем реально препятствует компрометации данных.

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

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

1. Торговое предприятие А проходит сертификацию на соответствие Стандарту, что подтверждается QSA (Qualified Security Assessor)[78].

2. Через некоторое время торговое предприятие А признается точкой компрометации данных платежных карт после успешной атаки со стороны злоумышленников.

3. PCI SSC выпускает поправки для аудиторов по процедурам проведения оценки на соответствие требованиям Стандарта по результатам данного инцидента.

4. При проверке торгового предприятия А по новым процедурам оно уже не соответствует требованиям.

Практика внедрения Стандарта показала, что одного формулирования требований безопасности недостаточно. Внедрение требований, управление требованиями, учет практических аспектов оказались недостаточно продуманными, что и привело к ряду обозначившихся проблем. По результатам исследования, проведенного Society of Payment Security Professionals, почти 24 % организаций, участвовавших в исследовании, потратили более 100 тыс. долл. США в год на оценку и соответствие требованиям Стандарта. А торговые предприятия уровня 1 (Level 1), по оценке Подкомитета, могут столкнуться с необходимостью ежегодных затрат в 18 млн долл. США на внедрение требований Стандарта, что превысит возможные потери от мошенничества. Компания Gartner оценила в 2008 г. затраты для приведения автоматизированной системы к соответствию требованиям Стандарта: уровень 1 — 2,7 млн долл. США, уровень 2 — 1,1 млн долл. США, уровень 3 — 155 тыс. долл. США. По оценке компании UCS (Россия), приведение системы к соответствию Стандарту составило 1 млн долл. США, поддержание соответствия — еще 100 тыс. долл. США ежегодно. Только ежегодные обязательные затраты на проведение аудита, пентеста[79] и четырех ежеквартальных сканирований составят около 1 млн руб.

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

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

Недостатки и противоречия PCI DSS

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

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

Стандарт предназначен для тех организаций и процессов, в которых номер карты передается, обрабатывается или хранится. Номер карты предназначен для обеспечения соответствия счету держателя карты, т. е. является его идентификатором. Безопасность такого доступа обеспечивается процедурами аутентификации держателя карты, которые должны препятствовать несанкционированному доступу к счету. Логично предположить, что для обеспечения безопасности доступа к счету при наличии фактов несанкционированного использования карты как инструмента доступа необходимо усовершенствовать процедуры аутентификации. Такое усовершенствование может включать в себя внедрение механизмов многофакторной аутентификации, например Chip&PIN, CAP-EMV. Однако Стандарт предполагает сокрытие идентификатора (номера карты) как обязательное условие обеспечения безопасности доступа. Очевидно, что принципиально невозможно отказаться от полного сокрытия идентификатора — для проведения транзакции по карте номер необходим, так как является идентификатором счета держателя карты.

Рассмотрим возможные действия злоумышленника, имеющего доступ к данным карты или ее реквизитам. Для проведения операции с реальной (физически существующей) картой необходима информация, записанная в чип (для микропроцессорных карт) либо на магнитную полосу. Знания только номера карты явно недостаточно, чтобы изготовить поддельную микропроцессорную карту. Для осуществления операции с использованием магнитной полосы кроме номера карты злоумышленнику дополнительно необходимо получить дату действия карты, код проверки подлинности карты (CVV/CVC) и сервис-код, который у аналогичных типов карт обычно одинаковый. Дату действия карты получить достаточно просто — путем хищения из того же источника, где был похищен сам номер карты, от держателя карты с использованием технологий фишинга, перебором. Код CVV/CVC получить гораздо сложнее — он записан на магнитной полосе карты, хранение данных которой любым участником платежной системы после проведения авторизации запрещено. Таким образом, похитить CVV/CVC при хранении нельзя, так как эти данные просто нигде не должны храниться. С помощью фишинга данный код получить невозможно, поскольку держатель его не знает. При использовании злоумышленником техники перебора всех возможных вариантов кода (три цифры дают 1000 вариантов) современный уровень систем мониторинга транзакций в режиме реального или псевдореального времени позволяет выявить данную атаку на ранней стадии и заблокировать карту. В случае же если эмитент записывает на магнитную полосу карты и код проверки подлинности ПИН (PVV), состоящий из четырех цифр (10 000 вариантов), то задача по подбору злоумышленником кодов безопасности становится существенно более трудоемкой (подобрать нужно комбинацию из семи цифр — 10 000 000 вариантов). Дополнительно необходимо отметить, что с учетом темпов EMV-миграции как со стороны эмиссии, так и со стороны эквайринга, особенно в Европе, и с отменой возможности проведения операции по микропроцессорной EMV-карте в EMV-терминале по магнитной полосе вероятность финансовых потерь в случае компрометации трека снижается с каждым годом. Смещение таких мошеннических операций в мировом масштабе происходит в регионы, где EMV-миграция не начиналась или проходит неактивно.

Второй сферой технологии платежных карт, где несанкционированно может быть использован похищенный номер карты, является интернет-коммерция. Действительно, в последнее время в данной области потери во всем мире стремительно возрастают. Сократить их должна безопасная технология проведения платежей 3D Secure, которая предусматривает дополнительную аутентификацию держателя со стороны эмитента. При реализации данной схемы (как со стороны эмитента, так и со стороны эквайрера) знание злоумышленником только номера платежной карты становится недостаточным. Следовательно, для минимизации потерь необходимо дальнейшее развитие технологии 3D Secure, особенно со стороны эмитентов. Однако в данном вопросе необходимо отметить следующие аспекты. Если интернет-транзакция проводится по традиционной схеме, без использования технологии 3D Secure, то для авторизации необходим номер карты, срок ее действия и код проверки подлинности карты CVV2/CVC2 — эти данные могут быть достаточно легко скомпрометированы. Учитывая перенос ответственности за несанкционированные держателями платежных карт операции, эквайреры повсеместно применяют более защищенную технологию 3D Secure, где перечисленных выше данных будет уже недостаточно. Но проблема заключается в трудности привлечения держателей карт для использования данной технологии даже в случае сертификации банка эмитента как 3D Secure. Во-первых, предлагаемые платежными системами методы Verified by VISA — Token Based Authentication и Secure Code — Chip Authentication Program не нашли в настоящий момент широкого распространения среди держателей, так как требуют от последних дополнительных затрат на приобретение оборудования, необходимости посещения банка, затрат на обучение. Во-вторых, если интернет-операция проводится между эквайрером, поддерживающим 3D Secure, и эмитентом, не поддерживающим 3D Secure, либо на 3D Secure, не подписан данный держатель, то согласно требованиям платежных систем уровень безопасности такой транзакции оказывается даже ниже, чем при классической операции. Дело в том, что такая операция может быть осуществлена только по номеру карты и дате ее действия, код проверки подлинности карты CVV2/CVC2 эквайрером может не запрашиваться. При этом, как правило, эмитент проверяет, что введенная дата действия карты больше текущей и в базе данных эмитента срок действия карты не закончился. А для обеспечения возможности работы двух карт одновременно при плановом перевыпуске не сравниваются даты из базы данных и транзакции. Таким образом, для осуществления успешной мошеннической операции необязательно даже знать срок действия карты — достаточно, чтобы он был больше текущей даты. То есть при реализации транзакции с поддержкой 3D Secure только со стороны эквайрера необходимо знать только номер карты и интернет-потери возрастают! Для обеспечения уровня безопасности при таких операциях, равного стандартному, эквайреру необходимо запрашивать код CVV2/CVC2. Для решения проблемы нежелания держателей подписываться на технологию 3D Secure для дополнительной аутентификации держателей, вероятно, нужно использовать технологию мобильной связи как наиболее распространенную и доступную клиентам.

Таким образом, при современных технологиях платежных карт номер карты не относится к критически важным данным — проведение несанкционированной операции возможно либо при нарушении требований безопасности, либо при отставании от передовых технологий, таких как EMV и 3D Secure.

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

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

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

Данные расходы могут состоять из затрат на проведение аудита, пен-теста, ежеквартальных сканирований сети, мероприятий по приведению автоматизированной системы торговца в соответствие с требованиями, в том числе расходы на приобретение оборудования, программного обеспечения (соответствующего, помимо прочего, требованиям стандарта безопасности PA-DSS), принятие в штат или обучение сотрудников. У торговцев в России в настоящий момент нет никаких стимулов соответствовать данному Стандарту. Эквайрер же может понести штрафные санкции, если у его торговца произойдет компрометация данных платежных карт, а торговец окажется несертифицированным. Отсюда следует, что данные расходы, вероятнее всего, будет нести именно эквайрер, поэтому эквайрер будет крайне заинтересован не показывать платежным системам крупных торговцев путем регистрации их в платежной системе как нескольких более мелких. Для небольших торговцев необходимо проходить ежеквартальные сканирования сети и заполнять специальный опросный лист, на основании которого и делается заключение о соответствии требованиям Стандарта. По логике данный опросник должен заполнить сам торговец, так как только он знает, как у него организована защита информации. Но поскольку, как уже отмечалось, торговец не заинтересован в прохождении процедур сертификации, а это как минимум выделение человеческих ресурсов, то скорее всего данный опросный лист будет заполнять сам эквайрер. И здесь возникает интересная ситуация. Если эквайрер ответит на все вопросы «как есть», то, во-первых, это займет с его стороны гораздо больше времени для выяснения истинного положения дел у торговца, а во-вторых, будет вероятность того, что торговец не соответствует требованиям Стандарта. Это, в свою очередь, связано с риском штрафов для эквайрера от платежных систем в случае компрометации данных у торговца и ведет к необходимости приведения сети торговца в соответствие требованиям Стандарта (опять же за счет эквайрера). В случае если эквайрер ответит на вопросы «как надо», то это сэкономит ему существенные ресурсы, а также ликвидирует риск применения штрафных санкций со стороны платежной системы.

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

4. Существует ряд юридических аспектов в РФ для банков, которые следует отметить. По требованиям Федерального закона от 27 июля 2006 г. № 152-ФЗ «О персональных данных» и Стандарта Банка России СТО БР ИББС-1.0-2010 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Общие положения», который в настоящее время носит рекомендательный характер, банки и так внедряют системы защиты данных в соответствии с этими требованиями, причем сами требования принципиально не отличаются от требований Стандарта. Это означает, что общая стоимость защиты различных используемых банком автоматизированных систем еще более возрастет, при этом целесообразность этого не является бесспорной и достаточно обоснованной применительно к российским условиям.

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

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

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

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

В связи с этим более перспективным является другой путь обеспечения безопасности, а именно — не защита существующих уязвимых платежных технологий, требующая дополнительных инвестиций, а миграция на более современные и защищенные технологии, включая EMV и 3D-Secure, на которые участниками рынка уже потрачены значительные средства.