17 августа 2012, 16:17
Количество просмотров 153

PA-DSS для банков: панацея или новый камень на шею?

Анна Гольдштейн, заместитель директора департамента аудита компании "Информзащита" Основной целью разработки стандарта PA-DSS стала...
PA-DSS для банков: панацея или новый камень на шею?



Анна Гольдштейн, заместитель директора департамента аудита компании "Информзащита"

Основной целью разработки стандарта PA-DSS стала необходимость поддержки внедрения PCI DSS. Насколько серьезной проблемой становится внедрение этой новой инициативы для банка-эквайера? И наоборот, может ли она послужить ему хорошим подспорьем для достижения PCI DSS Compliance?


Прежде чем перейти к основной теме настоящей статьи, хотелось бы дать некоторую общую характеристику стандарту PA-DSS. Итак, перечислим его основные особенности:
• Требования стандарта направлены на вендора (разработчика) платежных приложений.
• Стандарт является прямым наследником VISA PABP.
• Дата выхода первой версии PA DSS: апрель 2008.
• Разработчик стандарта – Совет PCI SSC, в который входят 5 международных платежных систем.
• Подтверждение соответствия стандарту осуществляется путем сертификации. Сертификационный орган должен иметь статус PA QSA (для получения которого необходимо, в том числе, иметь статус аудитора PCI DSS).

Основной целью разработки PA-DSS стала необходимость поддержки внедрения стандарта PCI DSS. Дело в том, что до выхода в свет этого стандарта большинство компаний, в том числе российских, попадающих под требования ранее разработанного стандарта PCI DSS, сталкивалось с рядом проблем в процессе достижения PCI DSS Compliance. В чем же они заключались, и каким образом появление PA-DSS может способствовать их разрешению?

1. Явные нарушения требований стандарта PCI DSS, которые банк самостоятельно не может исправить по причине того, что эти нарушения являются следствием работы закупленных банком приложений, в которых отсутствует возможность настройки. Из наиболее критичных нарушений – сохранение запрещенных данных авторизации: треков, CVV2/CVC2 ипр. Подобное нарушение обычно выявляется уже при первом аудите PCI DSS в 100% случаев.

2. Невозможность/сложность удаления тех же данных авторизации, сохраняемых старыми версиями приложений, из текущих журналов транзакций и других архивов, хранение которых необходимо по тем или иным объективным причинам. Иными словами, вендор доработал приложение, и оно больше не сохраняет эти данные, банк внедрил новые «PCI DSS compliant» версии, а нарушение PCI DSS в части хранения данных авторизации в старых архивах все равно осталось не устраненным.

3. Дополнительная нагрузка в виде необходимости самостоятельно продумывать защитные меры по реализации следующих требований стандарта PCI DSS в отношении приложений, обрабатывающих данные держателей карт:
• Запрет хранения номеров карт в открытом виде;
• Реализация парольной политики;
• Протоколирование доступа к данным держателей карт и использования административных привилегий;
 • и т.п.

4. Невозможность выполнения других требований PCI DSS из-за противоречий с требованиями вендора используемого платежного приложения. Например, зачастую банкам приходится выбирать: или устанавливать последние обновления безопасности на Oracle в соответствии с требованиями стандарта и при этом нарушать контракт по поддержке с вендором, гарантирующим работоспособность приложения только для определенной версии Oracle без установленных обновлений безопасности, или, как в итоге поступает большинство из них, – не устанавливать обновления и нарушать тем самым требования стандарта PCI DSS. Пока для бизнеса последний вариант обходится дешевле.
Итак, для того чтобы устранить перечисленные проблемы, в положения стандарта PA-DSS были включены:
• все применимые к прикладному уровню платежных приложений требования PCI DSS;
• требования, гарантирующие возможность установки приложения в PCI DSS сертифицированную среду, т.е. необходимость следования всем принципам безопасной работы в сетевой инфраструктуре клиента, использующего данное приложение;
• требования к процессам разработки и поддержки приложений вендором, гарантирующие контроль уровня безопасности приложения в дальнейшем, а также призванные решить конфликт между положениями PCI DSS и требованиями вендора к поддерживаемому им системному ПО, необходимому для работы приложения.
Единственным заметным отличием PADSS от своего «старшего брата» стало отсутствие возможности применения «компенсационных мер», т.е. альтернативных мер для снижения рисков в области обеспечения безопасности данных по отношению к мерам, требуемым положениями стандарта. Думаю, несложно догадаться, почему это было исключено в PA-DSS: если бы такая возможность в нем сохранилась, то большое число требований этого стандарта так и осталось бы невыполненным разработчиками платежного приложения, а связанные с этим проблемы были бы «технично» перенесены ими на использующего это приложение клиента – все тот же банк.
Вопросы же применения стандарта PADSS, по аналогии с PCI DSS, решаются каждой из международных платежных систем в составе PCI SSC независимо друг от друга, причем все они (кроме Visa) пока оставляют для своих участников и их мерчантов право выбора, как именно выполнять требования «старшего брата», т.е.
PCI DSS, – с использованием сертифицированных по PA-DSS приложений или без оных. В свою очередь, Visa традиционно пошла дальше и опубликовала для каждого региона обязательные сроки по переходу на использование исключительно сертифицированных по PA-DSS приложений для работы со своими картами. В России и других государствах, за исключением Североамериканского континента, такой переход предусматривает два этапа:
1. Новые мерчанты обязаны соответствовать PCI DSS или использовать ПО, сертифицированное по PA-DSS, с 1 июля 2010г.
2. Эквайеры обязаны удостовериться, что все мерчанты и агенты используют ПО, сертифицированное по PA-DSS, до 1июля 2012г.
В США и Канаде для окончательной миграции были установлены еще более ранние даты – на этих рынках «электрификация всей страны» должна успешно завершиться уже к 1 июля 2010г.
Как мы можем наблюдать, платежные системы по-прежнему видят слабым звеном именно мерчантов и отводят ведущую роль в своих программах достижения PCI DSS Compliance именно банкам-эквайерам. Однако попробуем разобраться, насколько серьезной проблемой появление PA-DSS становится для банка-эквайера.
На самом деле совершенно аналогичные сроки по приведению IT-инфраструктуры в соответствие с требованиями PCI DSS установлены для мерчантов достаточно давно. Речь идет о следующих требованиях:
1. Запрет хранения авторизационных данных (треков, CVV2/CVC2, PIN/PINBLOCK) для мерчантов с 1-го по 3-й уровень – с 30 сентября 2009г.
2. Соответствие PCI DSS – сентябрь 2010г. для мерчантов 1-го уровня.
При этом и Visa и MasterCard установили достаточно жесткие требования к отчетности эквайеров за своих мерчантов, а также к степени соответствия последних PCI DSS. Однако в России все эти правила не работают – просто за неимением мерчантов соответствующего уровня. Как известно, уровень мерчанта определяется по совокупному количеству карточных транзакций, а большинство крупных розничных торгово-сервисных сетей в России с формальной точки зрения являются не более чем большим количеством отдельных мерчантов с весьма низким количеством транзакций у каждого. Поэтому львиная доля российских мерчантов совершенно законно относится к 4-му уровню, требования по соответствию PCI DSS к которым определяет сам банк-эквайер.
Но вернемся к PA-DSS. Как ни странно, именно здесь специфика российских отношений между банком-эквайером и розничными торгово-сервисными сетями может сыграть против банка и повысить значимость использования сертифицированных по PA-DSS приложений к установленному Visa сроку. Это может случиться по причине того, что существующие мерчанты могут продолжать использовать несертифицированные приложения до 2012г., а вот «newly signed merchants» переходить на PA-DSS приложения придется на 2 года раньше – то есть уже с лета 2010 года.
Оставляя за кадром очевидное и вполне понятное нежелание эквайера оказывать какое-либо давление на своих мерчантов, а также технические сложности замены приложений для мерчантов, попробуем ответить на актуальный вопрос: а есть ли сегодня на российском рынке PA-DSS сертифицированные приложения? На сегодняшний день в опубликованный список PA-DSS сертифицированных приложений внесено почти 700 различных продуктов более 150 различных вендоров.
Около 60% из них в том или ином виде представляют собой решения для использования в POS-терминалах. К сожалению, пока практически ни одно из широко используемых российскими мерчантами приложений не имеет заветного сертификата – более 95% приложений из этого списка предназначены для рынка США.
Справедливости ради следует отметить, что в последнее время российские разработчики программных решений для POS-терминалов заметно активизировались и приступили к процессу PA-DSS сертификации своих продуктов. Учитывая, что подобные приложения обычно не являются особенно «громоздкими» с точки зрения функционала и представлены в виде отдельных модулей, приведение их в соответствие PA-DSS и последующая сертификация все же являют собой конечный и вполне предсказуемый по длительности процесс. Поэтому уже в ближайшем будущем на рынке в России появятся сертифицированные решения.
Противоположная ситуация наблюдается с системами автоматизации процессинговых центров. Здесь рынок раскололся на две половины – одни вендоры провели сертификацию своих продуктов еще на заре внедрения стандарта PA-DSS, другие пока даже не готовы отвечать на вопросы клиентов о предположительных сроках сертификации. Сертификация же таких приложений может занять длительное время, особенно если вендору придется с нуля адаптировать свои процессы разработки под новые требования к обеспечению безопасности.
Из наиболее часто используемых в российских процессингах приложений восьми вендоров на момент написания статьи только пять имело сертифицированные версии.
Более подробную информацию можно получить по ссылке на сайте PCI SSC https://www.pcisecuritystandards.org/security_standards/vpa/ При этом многие вендоры предложений для торгово-сервисных организаций (в том числе большого количества решений в области e-commerce) пока рассматривают вопрос сертификации только как возможное конкурентное преимущество для продвижения своего продукта и не имеют четко обозначенных планов по сертификации.
Что же реально дает PA-DSS сертификация? Перед глазами живо рисуется идеалистическая картинка безопасного мира карточных платежей: банк строит безопасную сетевую инфраструктуру, организует процессы управления информационной безопасностью и больше не мучается от головной боли, решая задачу PCI DSS Compliance. Вендор разрабатывает самые безопасные в мире приложения и приносит их вместе с перевязанной розовой ленточкой подробной инструкцией, как работать с этими приложениями и оставаться в рамках требований PCI DSS.
Однако придется добавить немного дегтя в эту бочку приторно сладкого меда.
Первое опасное заблуждение: «раз мы установили сертифицированное приложение, значит, мы достигли PCI DSS Compliance». На самом деле это приложение как минимум нужно еще настроить и поддерживать в соответствии с разработанным вендором специальным руководством, где написано, как выполнить то или иное требование стандарта. Как максимум – в руководстве напротив требования по шифрованию данных может быть написано «возьмите всю доступную документацию Oracle и придумайте что-нибудь» или «приложение может забывать удалять сохраненные во временных таблицах треки по транзакциям, по которым так и не получило корректного ответа от хоста». К сожалению, в силу небольшой практики применения стандарта PA-DSS и короткого срока, прошедшего с момента ввода программы контроля качества со стороны его авторов (PCI SSC), такая ситуация действительно возможна, хотя и является скорее исключением из общего правила.
Еще один минус – традиционно затраты на PA-DSS сертификацию приложения явно или неявно перекладываются на приобретающих его клиентов. Хотя стоит отметить, что поскольку набор требований в стандарте четко определен, то, заплатив за сертифицированную версию, можно по крайней мере на законных основаниях требовать достаточно много от вендора приложения. Для сравнения, совсем недавно банки были вынуждены в одиночку торговаться со своими вендорами по поводу цены за доработку их продуктов, представляющую всего лишь устранение замечаний аудитора PCI DSS.
Также не стоит забывать, что на соответствие стандарту PA-DSS сертифицируется только конкретная версия приложения. Далее все вносимые разработчиком после сертификации изменения делятся на два вида:
• не затрагивающие вопросы обеспечения безопасности и платежные процессы: для таких изменений требуется анализ аудитора, проводившего PA-DSS сертификацию, для подтверждения факта отсутствия влияния на соответствие требованиям стандарта;
• затрагивающие вопросы обеспечения безопасности или реализацию платежного процесса: для таких изменений необходимо проведение дополнительных сертификационных проверок.
По этой причине мало выбрать вендора, имеющего в своем активе одну сертифицированную версию приложения: использование новой версии этого приложения, не прошедшей процесс сертификации, с точки зрения платежной системы окажется равносильным использованию несертифицированного приложения.
Ну и, пожалуй, самое важное. Несмотря на провозглашенную цель внедрения (поддержка стандарта PCI DSS), область применения PA-DSS значительно уже, чем у его «старшего брата». Об этом свидетельствует следующий фрагмент из спецификации стандарта: “The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement”. Иными словами, из области применения PA-DSS выпали приложения, не участвующие непосредственно в осуществлении платежа, но предоставляющие различные сопутствующие сервисы. Часть из них обрабатывает не только номера платежных карт, риски компрометации которых (без компрометации остальных критичных данных) осмеивает банковское сообщество, но и другие наборы данных (например, речь идет о приложениях, реализующих мониторинг подозрительных транзакций, которые просто копируют себе весь трафик авторизационных запросов). Налицо парадоксальная ситуация: требования PCI DSS к банку, использующему эти приложения, никто не отменял, однако PA-DSS сертификация подобных приложений не предусмотрена, поэтому решать ее банку придется по старинке, т.е. в одиночку.
В заключение хочется отметить: конечно же, PA-DSS не решит всех проблем, да и навязывание «сверху» способов защиты с учетом разного представления у платежных систем и их участников об имеющихся рисках всегда будет обоснованно вызывать негативную реакцию. Однако при этом нельзя забывать о существовании ранее неразрешимых проблем достижения PCI DSS Compliance, с которыми PA-DSS позволяет эффективно бороться. Поэтому разумно стремиться извлечь из появления данного стандарта все возможные плюсы. А главное – не создавать себе дополнительных проблем, оттягивая процесс сертификации/миграции на «последний день».


Полный текст статьи читайте в журнале "ПЛАС" 3 (155) ’2010 сс. 27 - 30

Рубрика:
{}
Теги:
#

PLUSworld в соцсетях:
telegram
vk
dzen
youtube