курс цб на 26.03:
57.4247
61.8636
Лента новостей

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

Количество просмотров9 просмотров
Want create site? Find Free WordPress Themes and plugins.



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


Основной целью разработки стандарта 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

Did you find apk for android? You can find new Free Android Games and apps.




В рубриках:
Журнал ПЛАС № 3 (155) 2010

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *